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ABSTRACT 


Structure  Query  Language  (SQL)  and  Query  By  Example  (QBE)  are  the  most  widely 
used  query  languages  for  Relational  Database  Management  Systems  (RDBMS’s). 
However,  both  of  them  have  problems  concerning  ease-of-use  issues,  especially  in 
expressing  universal  quantification,  specifying  complex  nested  queries,  and  flexibility  and 
consistency  in  specifying  queries  with  respect  to  data  retrieval  To  alleviate  these  problems, 
a  new  query  language  called  “Dataflow  ()uery  Language”  (DFQL)  was  proposed. 

This  thesis  investigates  the  relative  strengths  and  weaknesses  of  these  three  languages. 
We  divide  queries  into  four  categories:  single-value,  set-value,  statistical  result,  and  set- 
count  value.  In  each  category,  a  representative  set  of  queries  from  each  language  is 
specified  and  compared.  Some  of  the  queries  specified  are  logical  extensions  of  the  other 
(already  defined)  queries,  which  are  used  to  analyze  the  query  languages*  flexibility  and 
consistency  in  formulating  logically  related  queries.  We  perform  a  siiiqrle  etqretiment  of 
asking  NFS  CS  students  to  write  a  small  set  of  queries  in  all  three  languages. 

Based  on  the  analysis,  we  conclude  that  DFQL  eliminates  the  problems  of  SQL  and 
QBE  mentioned  above.  The  relative  strengths  of  DFQL  comes  mainly  from  its  strict 
adherence  to  relational  algebra  and  dataflow-based  visually. 


TABLE  OF  CONTENTS 


1.  INTRODUCTION . 1 

A  BACKGROUND . 1 

B.  MOTIVATION . 2 

C  OBJECTIVE . 3 

D.  CHAPTER  SUMMARY  . . 4 

n.  DESCRIPTION  OF  THE  RELATIONAL  MODEL  AND  QUERY  LANGUAGES 

FOR  RDBMS’s . 5 

A  THE  RELATIONAL  MODEL  CONCEPTS . 5 

1.  FcnmalTenninology  ..... . 6 

Z  Rtoperdes  of  Relation . 8 

B.  TEXT-BASED  QUERY  LANGUAGES . . 8 

1.  TheRdadcmalAlgefaca _ ...... . 8 

2.  The  RelaticHial  Calculus..................... . 10 

3.  Stroctuce  Query  Language  (SQL)  . . 10 

a.  Data  Definition  in  SQL . 11 

b.  Data  Manqmlation - .... - .11 

c.  Logical  (Jperattns  of  SQL . 13 

d.  The  ftoUems  widi  S(?L . 13 

(1)  Declarative  Nature . 14 

(2)  Universal  (Quantification . IS 

(3)  Lack  of  Orthogonality . . 17 

(4)  Nesting  Construct . . . 17 

C  VISUAL-BASED  QUERY  LANGUAGES . 18 

1.  QBE,  a  Fomi-baaed  (Quay  Language . 18 

a.  Data  Retrieval . . 19 

b.  Built-in  functions,  Gbroiq)ing  and  other  (Jpoators . 20 

c.  The  ProUems  widi  QBE _ _ — - - 21 

hr 


2.  DataFlow  Quexy  Language  (DFQL) . 21 

a.  DFQL  Operators . 22 

(1)  Basic  Operators . 23 

(2)  Other  Primitives  Operators . 26 

(3)  Display  Opoators . 29 

(4)  User-defined  Operators . 29 

(5)  DFQL  Query  Construction . 29 

(6)  Incremental  Queries . 30 

(7)  Universal  Quantification . 30 

(8)  Nesting  and  Functional  Notation . 3 1 

(9)  Graph  Structure  of  DFQL  Query . 31 

3.  Entity-Relationship  Model  Interface . 31 

THE  COMPARISON  OF  SQL,  QBE,  AND  DFQL  WITH  RESPECT  TO 

DATA  RETRIEVAL  CAPABILITIES . 34 

A.  CATEGORIES  OF  QUERY . . 35 

1.  Single-Value .......... . 35 

a.  Query  1:  Simple  retrieval . 36 

b.  Query  2:  Qualified  retrieval . 38 

c.  Query  3:  Retrieval  involves  more  than  two  tables . 40 

d.  QiKry  4:  R^rieval  involving  universal  quantification . 42 

e.  Query  5:  Retrieval  involving  a  negation  statement . 44 

2.  Set- Value . 47 

a.  Query  6:  Retrieval  involving  existential  and  universal 

quantification . 47 

b.  Qiwry  7:  Retrieval  involving  e7q>licit  sets . 49 

c.  Query  8:  Retrieval  involving  explicit  sets . 51 

d.  Query  9:  Retrieval  involving  universal  quantification . 54 

e.  Query  10:  Retrieval  involving  existential  and  universal 

quantification . 57 

f.  Query  1 1:  Retrieval  involving  set  operation . 59 


B. 


3.  Statistical  Result . 62 

a.  Quay  12:  Retrieval  involving  aggregate  AVG  function . 62 

b.  Query  13:  Retrieval  involving  AVG  and  Groupnig  function  ....64 

c.  Query  14:  Retrieval  involving  Count,  AVG,  and  Grouping 

function . 66 

d.  Query  IS:  Retrieval  involving  Count  and  AVG  function . 68 

e.  Query  16:  Retrieval  involving  Max  and  Grouping  function . 70 

f.  Query  17:  Retrieval  involving  Max  and  Grouping  function . 72 


g.  Query  18:  Retrieval  involving  Avg,  Max,  Sum,  and  Grouping 
function . 74 


h.  Query  19:  Retrieval  involving  Count  and  Grouping  function  ...76 
4.  Sa-Count  Value . 79 

a.  Query  20:  Retrieval  involving  existential  quantification 79 

b.  Query  21:  Retrieval  involving  Count  and  Grouping  function  ...81 

c.  Quay  22:  Retrieval  involving  Count  and  Grouping  function  ...84 

d.  Query  23:  Retrieval  involving  Count  ftmction . 87 

e.  Query  24:  Retrieval  involving  universal  quantification  ............89 

f.  Query  25:  Retrieval  involving  universai  quantification  ............91 

ANALYSIS  _ _ 93 

1.  Ease^f-use . 93 

a.  Quoies  involving  existential  or  universal  quantification - 94 

(1)  SQL . 94 

(2)  QBE . 95 

(3)  DFQL . . 95 

b.  Queries  involving  nested  queries . 96 

(1)  SQL _ 96 


QBE 


. 96 


(3)  DFQL 


96 


2.  Flexihfliiy _ _ _ _ _ 

. 98 

a. 

SOL _ _ _ _ 

. 98 

b. 

QBE . . 98 

c. 

_ 99 

vi 


3.  Consistency . 99 

a.  SQL . 100 

b.  QBE . 100 

c.  DFQL . 100 

4.  Relative  Strengths  and  Weaknesses . 101 

IV.  HUMAN  FACTORS  EXPERIMENT . Ill 

A.  HUMAN  FACTORS  ANALYSIS  OF  QUERY  LANGUAGES . Ill 

B.  EXPERIMENTAL  COMPARISON  OF  SQL,  QBE,  AND  DFQL  ...111 

1.  Assesment  of  the  Experiment . Ill 

a.  Subjects . 112 

b.  Teaching  Method . 112 

c.  Test  Queries . 112 

d.  Evaluation  Method . 113 

2.  E^qietiment  Results . 114 

3.  E3q)eriinent  Conclusion . 117 

a.  Quay  (Ql) . 117 

b.  Query  (Q2) . 117 

c.  Qijety(Q3) . 117 

d.  Query  (Q4). . 118 

d.  Query  (QS) . 118 


V.  CONCLUSIONS . 120 

LIST  OF  REFERENCES . 122 

APPENDIX  A . 125 

INITIAL  DISTRIBUTION  LIST . 128 


vn 


TABLE  2.1 
TABLE  2.2 

TABLE  3.1 

TABLE  4.1 
TABLE  4.2 

TABLE  4.3 


LIST  OF  TABLES 

BASIC  DFQL  OPERATORS  AND  THEIR  SQL  EQUIVALENTS  ....23 


NON-BASIC  DFQL  OPERATORS  AND  THEIR  SQL  EQUD'^A- 

LENTS . 26 

RELATIVE  STRENGTHS  AND  WEAKNESSES  OF  SQL,  QBE. 

AND  DFQL . 102 

EXPERIMENT  RESULT . 115 

PERCENT  CORRECT  OF  SUBJECT  CLASSMCATION  FOR 

Ql,  Q2,ANDQ3 . 116 

PERCENT  CORRECT  OF  SUBJECT  CLASSMCATION  FOR  Ql 
THROUGH  Q5 . 116 


viii 


LIST  OF  FIGURES 


Figure  2.1  A  Relation  STUDENT  Schema . 7 

Figure  2.2  Operator  Construction . 22 

Figure  2.3  ER-Diagram  of  the  COMPANY  database . 32 


tx 


LIST  OF  QUERIES 


Query  2. 1  Ei^ample  of  Relational  Algebra  Query . 9 

Query  2.2  Example  of  Relational  Calculus  Query  . 10 

Query  2.3  Example  of  SQL  Query . 16 

Query  2.4  Example  of  QBE  Query . 19 


X 


ACKNOWLEDGEMENTS 


I  would  like  to  thank  the  Indonesian  Navy  for  the  opportunity  to  study  at  the  Naval 
Postgraduate  School  (NPS)  in  Monterey,  California. 

I  would  like  to  thank  Dr.  C.  Thomas  Wu  for  his  continued  support,  enthusiasm, 
patience,  and  guidance.  These  were  invaluable  assets  for  the  completion  of  this  work.  I 
would  also  like  to  thank  LCDR  John  S.  Falby  for  his  help  and  support  in  editing.  His 
assistance  and  direction  were  both  enlightening  anrf  timely. 

I  wish  to  thank  to  Computer  Science  students  at  NPS  who  participated  in  a  human 
factors  expoiment.  These  support  was  instrumental  in  the  completion  of  this  thesis. 

I  am  very  grateful  to  my  paraits  for  their  support  and  faith.  Most  importandy,  I  am 
indebted  to  my  wife  Ediana,  my  daughter  Jean  Uatri  Augustine  and  my  son  John  Samuel 
Sebastian,  for  their  constant  love,  padoice  and  understanding. 


xi 


L  INTRODUCTION 


A.  BACKGROUND 

The  Relational  model  is  used  most  often  in  cuiient  commacial  Database 
Management  Systems  (DBMS’s)  compared  to  hierarchical  and  network  models,  since  it  is 
the  simplest  and  most  uniform  data  stracture  and  is  the  most  formal  in  nature  with  respect 
to  mathematical  logic  [Elma89].  The  theory  was  introduced  by  E.  F.  Codd  in  1969 
[Codd90].  Today,  numerous  con^anies  and  institutions  use  Relational  Database 
Management  Systems  (RDBMS’s)  in  many  different  kinds  of  software  packages  that  are 
equipped  with  several  manipulation  languages  (database  languages  or  query  languages). 
The  query  languages  that  have  been  implemented  and  ate  available  on  commercial 
DBMS’s  include  Stracture  (^ety  Language  (SQL)  and  (^ery  By  Example  (QBE). 

SQL  is  the  best  known  text-based  (line  orimted)  query  language.  Originally,  SQL 
was  known  as  SEQUEL,  and  was  introduced  in  1974  [Cham74].  The  earliest  version  of 
SQL  was  inq)lanaited  in  die  system  R  project  at  IBM  Research  Laboratory  in  San  Jose, 
California  [Asti76].  In  1986,  the  American  National  Standard  Institute  (ANSI)  approved  a 
standard  (function  and  syntax)  for  SQL  [ANSI86],  which  was  accepted  by  the  International 
Organization  for  Standardization  (ISO)  in  1987  [Date90a]. 

QBE  was  developed  by  IBM  in  1976  at  the  IBM  Yorktown  Heights  Research 
Laboratory,  NY.  [Zloo77].  It  is  the  ancestor  of  today’s  form-based  interfaces  (visual 
oriented  query  language).  In  QBE  the  query  is  specified  by  filling  in  a  proper  column  in 
fenm  of  tables  (relations)  displayed  on  the  screen,  instead  of  writing  linear  or  text 
statements. 
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B.  MOTIVATION 

SQL  and  QBE  are  two  commonly  used  query  languages  and  exist  together  in  several 

DBMS  products  (c.g.,  DB2^  SQL/DS^,  Oracle^,  dBase  IV*,  etc.).  However,  neither  of 
these  query  languages  have  succeeded  in  alleviating  the  problems  concerning  ease-of-use 
issues,  especially  in  expressing  universal  quantificadon,  specifying  complex  nested 
queries,  flexibility  and  consistency  in  specifying  queries  with  respect  to  data  retrievaL  As 
discus^  in  [DateS?],  SQL  does  not  posses  a  simple,  clean,  and  consistent  structure,  in 
either  its  syntax  and  semantics.  Codd  points  out  that  SQL  permits  duplicate  rows  in 
relations,  it  supports  an  inadequately  defined  kind  of  nesting  of  a  query  and  does  not 
adequately  support  three-valued  logic  [CoddSSa]  [Codd90].  In  [Ncgr89]  SQL  consttucts 
are  very  con^lex,  in  particular  Universal  quantification,  uitich  are  full  of  pitfalls  for  the 
inexpeiioiced  user.  In  contrast,  QBE  is  much  more  intuitive.  But  QBE  still  falls  short, 
providing  no  siqiport  for  edstential  or  universal  quantification  [Elma89]  [DatB90a]. 

Bi  order  to  aUeviate  the  problems  at  issue  above,  a  new  language  called  “Data  Flow 

Query  Language”  (DFQL)^  was  proposed.  DFQL  is  a  graphical  database  interfiK:e  based 
on  the  data  flow  paradigm.  DFQL  retains  all  the  power  of  current  query  languages  and  is 
equqiped  with  an  easy  to  use  facilify  for  extoiding  the  language  with  advanced  operators, 
tiius  providmg  query  facilities  beyond  the  benchmark  of  first-order  predicate  logic. 

Altiiough,  these  tinee  languages  are  all  relationally  complete^  [Date82]  [DatB84]  [Qar91] 
[Rran88],  tiius  expressive  powers  are  equivalent  However,  they  are  not  necessarily  equally 

1.  DB2  (IBM  DATABASE  2)  is  a  (tadeinnk  of  Jhieniational  Busmess  Machines  Qxponaion. 

2.  SC^VDaia  S3rstem  is  a  mdenuBk  of  Imenatioiiai  Business  Nbcliines  Coqxxatioa. 

3.  Onek  b  a  uademaA  of  Oncle  Cocporaikm. 

4.  dBase  IV  is  a  tndemaik  of  Ashion-TaiB. 

5.  inqdememed  by  Lt  (3«d  J.  Qaik  as  his  diesis  woifc  (see  Chapter  1LC2)  under  the 
sopervisaion  of  Dr.  C.  Thomas  Wu.  Conqiiner  Science  DqxBtment  at  Naval  Postgraduate  Schoed 
(NFS).  B  is  imiilBineaied  in  Ftognidi. 

[Hns92]. 
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useful.  For  example,  a  single  query  is  more  easily  specified  in  QBE  than  SQL.  A  number 
of  comparative  studies  of  two  or  three  query  languages  have  been  performed  [ReisVS] 
[RdsSl].  However,  no  direct  comparison  has  been  made  of  SQL,  QBE,  and  DFQL,  with 
req)ect  to  the  above  mentioned  problems.  Also,  a  simple  experiment  regarding  ease-of-use 
in  query  writing  for  these  three  languages  needs  to  be  accomplished. 

C.  OBJECTIVE 

The  focus  of  this  research  is  to  evaluate  whether  DFQL  can  alleviate  the  problems  at 
issue  faced  by  SQL  and  QBE  by  investigating  tfie  relative  strengths  and  weaknesses 
concerning  ease-of-use,  eq)ecia]ly  in  expressing  universal  quantification  and  specifying 
coiiq)lex  nested  queries.  A  Category-based  approach  of  comparing  query  languages  is 
developed.  Widi  this  iqtproach,  queries  ate  divided  into  four  categories:  single-vaiue^  set- 
value^  statistical  result,  set-count  value.  In  each  category,  a  representative  set  of  queries 
from  each  language  is  spedfied  and  conqured.  Some  of  the  quoies  q)ecified  are  logical 
extensions  of  other  (already  defined)  queries,  and  we  used  such  extension  types  of  queries 
are  used  to  analyze  the  query  languages’s  flexibility  and  consistency  in  formulating  a 
logically  related  queries.  In  addition,  a  siiiq)le  e]q)erimmt  of  asking  Naval  Postgraduate 
School  (NFS)  Computer  Sdence  (CS)  studoits  to  write  a  small  set  of  queries  in  all  diree 
languages  are  performed. 

Our  finding  in  dus  thesis  work  should  serve  as  a  basis  for  developingrinq^roving  the 
quffity  langu^e.  In  addition,  by  having  a  higher  level  of  understanding  on  the  relative 
strengAs  and  weaknesses  of  each  language  in  req^ective  query  categories,  we  will  be  able 
to  provide  or  recommend  a  suitable  query  language  depending  on  Ae  intended  users. 
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D.  CHAPTER  SUMMARY 


Chapter  n  presents  a  description  of  the  Relational  Model  concept,  SQL,  QBE,  and 
DFQL  and  discusses  the  problems  faced  by  SQL  and  QBE.  In  Chapter  EL  the  numerous 
queries  are  presented  by  each  category  and  composed  in  these  three  languages:  SQL,  QBE, 
and  DFQL.  The  relative  strengths  and  weaknesses  with  respect  to  data  retrieval  capabilities 
concerning  ease-of-use,  and  flexibility  and  consistency  in  specifying  the  queries  are 
discussed.  The  relational  schema  database  is  provided  in  Appendix  A.  Chapter  m  also 
provides  an  analysis  of  these  three  query  languages. 

Cluq>ter  IV  provides  a  discussion  and  analysis  of  a  simple  experiment  of  asking  NFS 
CS  students  to  write  a  small  set  of  queries  in  all  three  query  languages.  Chapter  V  provides 
aconclusiotL 
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n.  DESCRIPTION  OF  THE  RELATIONAL  MODEL  AND  QUERY 

LANGUAGES  FOR  RDBMS’s 

As  mentioned  previously,  the  Relational  Model  was  introduced  by  Qxkl  in  1969.  The 
basic  concepts  of  the  Relational  Model  are  needed  as  fundamental  knowledge  for  providing 
a  better  understanding  of  high-level  data  manipulation  languages  or  query  languages  with 
respect  to  query  specification  for  relational  database  retrieval  operation. 

Query  languages  for  RDBMS’s  can  be  classified  into  two  categories:  text-bascu 
languages  and  visual-based  langtu^es.  This  chapter  presents  the  Relational  Model 
concepts,  text-based  query  languages  and  visual-based  (or  graphical)  query  languages. 
Within  the  discussion  of  text-based  query  languages,  in  addition  to  discussion  of  relational 
algebra  and  relational  calculus,  we  particularly  focus  on  SQL.  The  visual  or  gnq)hical  query 
languages  discussion  qtedfically  enq)hasizes  QBE  and  DFQL  rather  than  the  Entity 
Rdationships  (ER)  modeL 

A  THE  RELATIONAL  MODEL  CONCEPTS 

The  relatitmal  modd  rqoesents  tte  data  in  a  database  as  a  coUectitm  of  relations.  A 
relation  is  a  mathematical  term  which  represents  a  simple  two-dimensional  table  structure, 
consisting  of  n-rows  and  m-colunms  that  contain  data  values.  In  other  words,  a  rdational 
database  is  a  collection  of  related  informadon,  or  data  values,  stored  in  two-dimensional 
tables. 

To  explain  die  reladonal  data  structure,  we  use  die  STUDENT  rdadon  (table)  in 
figure  2.1.  In  the  STUDENT  table,  data  is  logically  ordered  by  values  of  NAME,  SSN 
(stands  for  Social_Security_Number),  PHONEJIO,  ADDRESS,  and  GPA  for  each 
student  data.  Eadi  student  has  a  unique  itteitificadon  number,  rqiresented  by  SSN. 
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L  Fonnal  Temiiiotogy 

Hie  relational  database  has  its  own  tenninology  which  is  usually  used  in  RDBMS 
applications.  Examples  include  the  terms  relation,  attribute,  tuple,  domain,  degree, 
cardinality,  primary  key,  candidate  keys  and  foreign  key.  Consider  the  following  brief 
eaqplanation  of  diese  tenns: 

•  A  relation  coixesptmds  to  what  we  have  generally  been  calling  a  table. 

•  A  tuple  coneqioiuls  to  a  raw  in  such  a  table,  and  an  attribute  corre^nds  to  a  table 
cobmn. 

•  Cardinality  rqiresents  a  number  of  tiqiles,  and  die  number  of  attributes  is  called  the 
degree. 

•  The  primary  key  is  a  unique  identifier  for  a  table  ~  that  is,  a  column  or  column 

combinatum  wiA  die  prqiet^  that,  at  any  given  time,  no  two  rows  of  the  table  contain 

the  same  value  in  that  cohunn  or  column  ctrnibination. 

•  CmufidaieAeys  ate  sets  of  attributes  in  a  relation  that  could  be  chosoi  as  a  key. 

•  A  foreign  is  a  set  of  attributes  in  one  relation  diat  constitute  a  primary  key  of 
another  relation’s  (or  possibly  die  same)  table. 

^  A  dcffiotR  is  a  pool  of  values,  from  vdiich  one  or  mote  attiibntes  (columns)  draw  dieir 

actual  values  iPaie90a].  For  example,  the  domain  of  SSN  in  Hgute  2.1,  written 
doaKSSN),  is  the  set  of  all  legal  STUDENT  SSNs.  The  set  of  values  qipeaiing  in  the 
attribute  SSN  of  die  STUDENT  relation  at  any  time  is  a  subset  of  die  domain. 

Using  die  terms  above,  and  Hgme  2.1,  the  lelatioo  sdiema  for  the  STUDENT 
relation  has  degree  6,  which  is:  STUDENT  (NAME,  SSN,  PHONE  ADDRESS,  SEX, 

GPA).  The  attributes  have  the  following  domains:  d(mi(NAME)  s  Names,  dom(SSN)  » 
SociaLSecnti9_Nnnibets,  dom(FHONE^O)  «  LocaL.Phone_Nuiri)er, 
dmn(ADDRESS)  s  Addresses,  dom(Sex)  »  MaleyFemale,  dom(GPA)  « 
Grade..PoiiULAverages.  A  relation  r  of  the  rdation  sclrema  R  (Al,  A2, ......  An),  also 

denoted  by  r(R),  is  a  set  of  n-tiq>les  r  s  { tl,t2, tm  1 .  Each  n  tiqile  t  is  an  ordered  list  of 

n  values  t«<Vl,V2,.....,Vn>,whereeach  value  Vi,  l<*i<«n,isanelemaitofdom(Al) 
or  is  a  special  nul/ value.  Eadh  tuple  in  die  relation  rqnesents  a  particular  student  entity. 


6 


where  an  entity  is  an  object  that  is  rqmsented  in  the  database.  Null  values  represent 
attributes  whose  values  are  unknown  or  do  not  exist  for  some  individual  STUDENT  tuples 
[Elma89].  In  mathematical  terms,  a  relation  r(R)  is  a  subset  of  the  cartesian  product  of  the 
dtHnains  that  define  R. 

t(R)  £  (dom(Al)  X  dom(A2)  X _ X  dom(An)). 

UMiefore,  all  possible  condnnadons  of  values  from  the  underlying  domains  can 
be  qtecified  by  the  cartesian  product. 


NAME  SSN  PHONE.NO  ADDRESS  SEX  GPA 


Attributes 

Degree 


Figure  2.1:  A  Relation  STUDENT  Schema 
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2.  Properties  of  RdatkNis 


Rdations  possess  certain  propoties,  all  of  them  immediate  consequences  of  the 
defoiition  of  ‘*relation”.  Thoe  axe  four  properties,  as  follow  [Date  90a]: 

•  There  axe  no  diq)licate  tiq>les;  it  follows  the  fact  that  the  relation  is  a  mathematical  set 
(Le.  a  set  of  tuples),  and  sets  in  madtonatics  by  definition  do  not  include  duplicate 
elements.  An  inqiortant  corollary  is  that  there  always  exists  a  primary  key  in  a  relation. 
Since  each  tuple  is  unique,  it  follows  diat  at  least  the  combination  of  all  attributes  of 
die  lelatimi  has  the  uniqueness  property. 

•  Tdples  are  unoedered  within  a  relation  (top  to  bottom)  which  follov>  3  the  fact  that  sets 

in  madieinatics  are  not  ordered. 

•  AU  attribute  values  ate  atomic.  At  every  row-and-column  position  within  the  table, 
diete  always  exists  precisely  one  value,  never  a  list  of  values.  However,  a  special  value 
‘‘null”  is  used  as  a  colu"w  value  of  a  particular  tuple  which  is  either  “unknown”, 
“attribute  does  nen  qiply”,  or  “has  no  value”  in  it 

•  Attributes  are  nnordered  (left  to  right),  which  follows  die  fact  that  the  heading  of  a 
relation  is  also  defined  as  a  set  (Le.,  a  set  of  attributes,  or  more  accurately  attxibnte- 
domampaits). 


B.  TEXT-BASED  QUERY  LANGUAGES 

The  nature  of  text-  baaed  query  languages  is  diat  queries  are  written  in  normal  text 
editors  (text-baaed).  This  category  can  be  divided  into  dnee  subdasaes:  relational  algebra 
based,  lelatitmal  cakulus  based,  and  die  combinatkm  of  bodL  This  section  will  focus  on 

SCH^lfowever,  die  general  cOToept  of  die  relational  algdxa  and  rdattoial  calculus  is  also 

covered. 

L  TheRelatioiialAlfebra 

The  Relational  eUgebra  is  a  technique  for  ctmdjining  mathematKal  sets  that  have 
die  property  of  being  rdations  (tables);  it  was  proposed  by  Codd  [Codd70].  ft  is  said  to  be 
a  **procedun^  lanpmge,  which  means  diat  die  user  most  not  only  know  what  he  wants 

aiien  petfarming  tolerations  on  idaticms,  but  also  know  how  to  get  it  The  user  can  ^weify 
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a  sequence  (stq>  by  stq))  of  relatioiial  operations  to  be  performed  on  the  tabtes  of  the 
schema  to  pnroduce  a  desired  result  The  result  of  each  operation  forms  a  new  relation, 
which  can  be  tiirtiier  manqnilated.  In  other  words,  relational  operators  can  be  nested.  The 
opoiations  included  in  the  Relational  Model  are:  UNION,  INTERSECTION, 
DIFFERENCE,  CARTESIAN  PRODUCT,  SELECT,  PROJECT,  and  JOIN.  Consider  the 
query  otample  in  Query  2.1,  which  is  specified  using  relational  algebra.  The  English 
translation  of  tite  query  is:  “Retrieve  the  Erst  name,  last  name,  and  salary  of  enq>loyees  who 
wt»k  in  projea  Computerization”.  Notice  that  all  query  examples  in  this  chapter  are 
matched  to  a  relational  database  instance  of  the  COMPANY  schema  in  Appendix  A. 

COMPU_PROJ  ^  <y  fUAXlB  ■  “  (PROJECT) 

COMPU_PROJ_EMPS  ♦-  (COMPU.PROJ  X  ono  -  DNUM  EMPLOYEE) 
RESULT  <-  1C  fSAME,  LNAME,  SALAKT  (OOMPU_PROJ_EMPS) 

Query  2.1:  Ezanqiiet^Relntioiial  A^ebra  Query 

Rrom  die  query  above,  we  can  (tetermine  that: 

•  There  ate  three  lines  executed  in  sequence  to  give  die  desired  result 

•  Ihe  user  is  allowed  to  use  a  temporary  name  to  store  the  result  of  a  line  and  dwn  use 
that  name  as  an  input  to  sttbseqom  lines. 

•  The  query  is  written  in  a  procedural  language. 
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2.  'ne  Rdatkmal  Cakulus 

The  Relational  Calculus  was  also  proposed  by  Codd  [CoddTl].  In  relational 
calculus,  a  query  is  qiecified  in  a  single  step;  which  is  why  it  is  known  as  a  “non- 
proca/uraT  language.  However,  Cotki  showed  that  relational  calculus  and  relational 
algebra  axe  logically  equivalent,  where  any  query  specified  in  relational  calculus  can  be 
specified  in  relational  algebra  as  well,  and  vice  versa. 

hi  diis  type  of  query  language,  a  predicate  calculus  etqtression  is  used  to  specify 
the  tuples  desired.  If  Query  2.1  is  ^lecified  using  relational  calculus,  die  structure  is 
formulated  like  Query  2.2.  Here,  the  free  tuple  variables  “e”  and  “p”  are  used  to  make  the 
logical  connections  between  die  EMPLOYEE  (e)  and  PROJECT  (p)  relations,  according  to 
the  join  condition  and  selection  condition  specified  by  p.DNUM»e.DNO  and  p.PNAME 
*  ‘Computerization’  respectively.  The  fiee  tuple  variables  e.  FNAME,  e.  LNAME,  c. 
SALARY  ate  die  attributes  in  udiich  their  ttqples  ate  consideied  to  be  retrieved,  as  long  as 
itstnples  the  condition  specified  is  satisfiied. 

{e.  FNAME,  e.  LNAME,  e.  SALARYI  EMPLOYEE  (e)  and  0 pKPROJECT (p) 
and  p.  PNAME  » ‘Computerization’  and  p.  DNUM  *  e.  DNO)} 

Query  2J:  Example  of  Relational  Caicnlas  Query 

3.  Structure  Query  Language  (SQL) 

Hie  earliest  version  was  designed  and  irrqtleniented  by  IBM  Research  as  an 
imetfiKe  for  a  tdational  database  system  known  as  SYSTEM  R.  It  was  die  earliest  of  the 
Ugh-kvel  database  language  (non-procedural  languages).  Today  SQL  exists  in  several 
cofiunacial  RDBMS’s  products  such  as  IBM’s  DB2,  SQL/DS,  and  Oracle. 
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SQL  is  a  conqtreheosive  database  language:  it  has  statements  (text-based)  for  data 
definition  language  (DDL)  and  data  manipulation  language  (DML).  SQL  also  provides 
facilities  for  defining  views  on  a  database,  for  creating  and  dropping  indexes  on  the  files 
that  represent  relations,  and  for  embedding  SQL  statements  into  a  general  purpose  language 
such  as  PL/I  or  Pascal  [Elma89]. 

a.  Data  Definition  in  SQL 

As  a  SYSTEM  R  database  language,  SQL  implements  the  terms  table 
(relation),  row  (tuple),  and  column  (attribute).  The  SQL  commands  for  data  definition  are 
CREATE  TABLE,  ALTER  TABLE,  and  DROP  TABLE.  These  commands  are  used  to 
specify  the  attributes  of  a  relation,  to  add  an  attribute  to  a  relation,  and  to  delete  a  relation, 
reflectively. 

b.  Data  Manipulation 

SQL  contain  a  wide  variety  of  data  manipulation  capal^ties,  bofii  for 
querying  and  updating  dw  database.  However,  this  chapter  will  emphasize  the  features  of 

querying^  that  are  related  to  die  discussion  in  previous  chapter.  SQL  is  a  reladonally 
ctmiplete  language.  Rs  statements  direcdy  or  indirecdy  contain  some  basic  operators  of 
both  relational  algebra  and  relational  calculus.  However,  the  “SELECT”  statement  has  no 
rdationslup  to  die  “SELECT”  operation  of  relational  algebra.  SQL  allows  arelation  to  have 
two  or  more  tuples  that  ate  identical  in  their  attribute  values.  To  eliminate  the  duplicate 
tuples,  SQL  provides  the  keyword  “DISTINCT”  to  beusedinthe  SELECT-clause;  it  means 
that  only  distinct  tuples  should  remain  in  the  result  The  general  syntax  to  be  used  for 
retrieving  data  in  SQL  consists  of  up  to  six  clauses: 


1.  Qmy  in  DBMS  it  used  to  describe  data  retrieval,  not  update. 
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SELECT  <attnbate  list> 

FROM  <relation  list> 

(WHERE  <condition>] 

(GROUP  BY  <groiiping  attiibute(s)>] 

(HAVING  <grouping  condition>] 

[ORDER  BY  <attribttte  Ust>] 

•  SELECT-clause;  <attribute  list>  is  a  list  of  attribute  names  whose  values  are  to  be 
retrieved  by  the  query. 

•  FROM-clause;  <relation  list>  is  a  list  of  die  relation  names  required  in  the  query,  but 
not  diose  needed  in  nested  queries  level 

•  WHERE>claase:  <icondition>  is  a  conditional  (Boolean)  expression  that  idoitifies  the 
tuples  to  be  retrieved  by  the  query  frtrni  the  relation(s)  listed  in  the  FROM-clause. 

•  GROUP  BY-clause;  -^grouping  attribute(s)>  spedfks  grouping  according  to  each 
value  of  the  atttibute(s). 

•  HAVING-danse;  <grouping  condition>  specifies  a  condition  on  the  groiqis  being 
selected  radier  dian  on  the  individual  tuples. 

•  ORDER  BY-clause;  <attribute  list>  specifies  an  order  for  displaying  die  result  of  a 
query  (EIma89]. 

Notice,  if  the  SELECT-clause  and  FROM-clause  contain  more  than  one 
attribute  name  or  relation  name  respectively,  they  should  be  sqiarated  by  commas.  All 
attribute  luunes  listed  in  the  SELECT  or  WHERE  clauses  must  be  found  in  one  of  die 
relations  of  die  FROM-clause.  Ihe  basic  form  of  die  SELECT  statement  smnetimes  calls  a 
mapping  or  a  SELECT  FROM  WHERE  block.  Which  looks  like: 

SELECT  <attribute  list> 

FROM  <relation  list> 

WHERE  <condition> 

However,  only  the  first  two  clauses,  SELECT  and  FROM  are  mandatory.  SQL 
provutes  five  statistical  functions,  called  built-in  functions,  which  ate  COUNT,  SUM,  MIN, 
MAX.  and  AVG.  These  functions  examine  a  set  of  tuples  in  a  relation  and  produce  a  single 


value.  For  exanq)le>  the  COUNT  function  will  return  the  number  of  tuples  satisfying  the 
query.  On  the  other  hand,  the  functions  SUM,  MAX,  MIN,  and  AVG,  usuaUy  specified  in 
the  SELECT-clause  or  the  HAVING-clause,  are  ^>plied  to  a  set  or  multi-s^  of  numeric 
values  and  perform  the  indicated  operation  on  the  values. 

c.  Logietd  Operators  of  SQL 

The  logical  operators  normally  used  while  specifying  the  query  are: 

•  Coiiq)arison  operators:  =,  <  >,  <,  >,<=,>  s=. 

•  Boolean  connectives:  any  of  the  logical  connectives  AND,  OR,  NOT. 

•  IN  uses  in  nested  queries,  the  expression  evaluates  to  TRUE  if  there  is  included  at  least 
a  tuple  in  a  sub-query;  this  operator  corresponds  to  the  set  operator  “ir  a  member  of* 
which  is  symbolized  by  “€  " . 

•  and  always  precede  a  sub-query.  EX/OT  evaluates  to  TRUE  if 

the  set  resulting  from  a  sub-query  is  not  empty,  and  FALSE  otherwise.  This  opoator 
coneqxMids  to  the  madiematical  existential  quantifier  “3” .  The  NOT  EXISTS  is  the 
reverse  evaluating  to  TRUE  if  die  resulting  set  is  empty,  and  FALSE  odierwise.  This 
operator  corresponds  to  die  **every*  quantifier  in  die  condition;  the  mathematical 
universal  quantifier  CV*). 

•  LIKE  allows  die  user  to  obtain  around  the  fact  that  matching  to  each  value  which  is 
considered  atomic  and  indivisible. 

The  first  two  logical  operators  arc  normally  used  in  the  WHERE-clause.  The 
conqiarison  t^ietators  are  used  to  specify  the  selection  conditions  desired,  and  the  equality 
C*=”)  operator  is  used  to  qiedfy  the  join  condition  between  the  relations.  On  the  otha:  hand. 
Boolean  connectives  are  used  to  create  compound  condition  or  to  negate  a  condition 
[Elma89]  [1^88]  [Han892]. 

d.  The  Problems  with  SQL 

SQL  is  implemented  as  a  mixture  of  bodi  relational  calculus  and  relational 
aigdira  by  induding  the  nesting  ctqiability  and  block  stmctuie  feature.  However,  SQL 
tends  more  towards  the  relatumal  calculus  iqiproach;  it  is  primarily  declarative  in  nature 
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rather  Aan  a  procedural  language.  The  user  specifies  what  the  result  should  be  in  one 
statement  rather  than  in  a  sequence  of  statements.  Date  comments:  “When  the  language 
(SQL)  was  first  designed,  it  was  specifically  intended  to  differ  from  the  relational  calculus 
(and,  I  believe,  from  the  relational  algebra)....  As  time  went  by,  however,  it  turned  out  that 
certain  algebraic  and  calculus  features  were  necessary  after  aU,  and  the  language  grew  to 
accommodate  them”  [DateS?].  As  a  result,  it  is  a  strict  implementation  of  neither  relational 
algebra  nor  relational  calculus. 

(1)  Declarative  Nature.  As  mentioned  above,  SQL  is  primarily  a 
declarative  query  language.  As  a  matter  of  fact,  the  user  is  intended  to  construa  the  query 
based  on  relational  calculus  or  first-order  predicate  calculus  logic.  So,  all  of  the  conditions 
are  specified  in  a  single  statement  For  a  simple  query,  this  is  straight-forward  approach; 
for  more  complex  query  however,  the  logical  expression  required  to  specify  the  conditions 
to  be  met  can  become  quite  coiiqilicated.  This  problem  is  cottq>ounded  when  the  complex 
query  involves  universal  quantification  (discussed  later).  This  approach  may  not  always 
present  tire  clearest  representation  of  the  query  to  the  user.  Rrom  the  user  point  of  view,  we 
consider  that  it’s  related  to  human  nature  to  think  of  a  complex  problem  in  a  sequential 
fashion  rather  than  in  a  declarative  fashion  of  die  entire  the  problem  at  once. 

In  addition,  ease-of-use  issues  for  database  query  languages  relating 
to  inqnoving  the  human  factors  aqiect  have  become  evident  [Schn78].  Subsequoitly, 
human  factors  studies  have  berai  done  regarding  die  declarative  versus  procedural 
imptonoitations  of  query  languages.  The  result  of  these  studies  show  that,  for  complex  or 
difficult  queries,  the  users  perform  correctly  more  often  in  specifying  queries  when  using 
a  procedural  query  language  than  a  declarative  language  such  as  SQL  [WeltSl].  However, 
the  complexity  of  the  declarative  nature  of  SQL  is  compensated  for  by  embedding  SQL 
queries  into  a  procedural  third  generation  programming  language  such  as  PL/L  PASCAL, 
or  COBOL.  Here,  most  embedded  query  languages  give  the  user  the  ability  to  use  the  query 
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language  in  a  procedural  manner  if  desired.  In  this  way,  the  user  is  allowed  to  obtain 
advantage  of  the  features  of  die  host  language  to  accomplish  operations  that  are  very 
difficult  to  code  in  the  query  language. 

(2)  Universal  Quantification.  In  English  query,  the  idea  of  universal 
quantification  is  phrased  “for  all”.  This  kind  of  query  is  supported  indirectly  in  SQL,  which 
occurs  due  to  the  lack  of  a  specific  “for  all”  operator.  In  the  case  of  the  above  mentioned, 
SQL  forces  the  user  to  use  a  “NOT  EXI^'  operator  as  a  “negative  logic”  in  order  to  achieve 
the  effect  of  universal  quantification  and  “EXIST'  for  existential  quantification  in  a  nesting 
SELECT  statement  As  a  matter  of  fact  the  logical  meaning  of  these  operations  is  not 
completely  intuitive,  especially  to  the  inexperienced  user  who  is  not  accustomed  to  using 
predicate  logic.  When  using  the  logical  ideas  presented  by  these  operators,  most  individuals 
(of  users)  fall  into  error;  it  has  been  shown  to  be  difficult  to  use  them  correctly  even  when 
the  user  has  experience  in  this  area  [Negr89]. 

The  following  example  is  presented  to  show  how  SQL  expresses  the 
idea  of  universal  quantification  in  a  query;  in  fact,  it  is  somewhat  complicated.  If  the 
complexity  of  queries  increases,  then  the  difficulty  of  specifying  or  understanding  it 
increases  rtqndly.  Consider  the  following  relation  as  a  subset  of  a  database  schema  that  is 
presoited  in  Appendix  A  (key  attributes  are  undwlinedl. 

EMPLOYEE  (FNAME,  MINTT,  LNAME,  SSH  BDATE, 
ADDRESS,  SEX, 

SALARY,  SUPERSSN,  DNO) 

DEPARTMENT  (DNAME,  DNUMBER.  MGRSSN, 
MGRSTARTDATE) 

DEPENDENT  (ESSN,  DEPENDENT  NAME.  SEX,  BDATE, 
RELATIONSHIP) 


IS 


The  English  query  is:  ''Retrieve  the  department  names  in  which  all  of 
its  onployees  who  have  a  salary  more  than  $40,000  also  have  at  least  one  male  dependent”. 
The  SQL  query  is  given  in  Query  2.3. 


SELECT  DNAME 
FROM  DEPARTMENT 
WHERE  NOT  EXISTS  (SELECT  * 

FROM  EMPLOYEE 
WHERE  DNUMBER  =  DNO 
AND  SALARY  <  =  40000 
AND  EXISTS 
(SELECT  * 

FROM  DEPENDENT 
WHERE  SSN  =  ESSN 
AND  SEXo'M’)) 


Query  L3:  Example  of  SQL  Query 

The  query  inq>letnents  a  NOT  EXISTS  operator  in  the  WHERE- 
clanse  (in  the  third  line)  of  the  query  as  a  negative  logic  in  order  to  express  the  universal 
qnantificatioiL  The  attribute  SALARY  is  co!iq>aied  as  "less  than  or  equal  to”  instead  of 
"greater  than”  in  die  "outer”  nested  query  and  die  attribute  SEX  is  also  compared  as  "not 
equal”  rather  than  “equal”  in  the  "inner”  nested  query  where  the  logic  of  “there  exists”  is 
used  for  die  dependents.  Iherefore,  a  direct  English  translation  of  the  SQL  query  above  is: 
"Select  the  names  of  dqpartments  such  that  there  does  not  exist  any  employee  whose  salary 
is  less  dian  or  equal  to  $40,000,  and  there  exists  at  least  one  dependent  that  is  not  "male”. 
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The  specification  requited  to  form  the  query  above  is  not  straight  forward  at  all;  the  query 
formulation  involves  negative  logic  that  is  extremely  easy  to  mix-up,  even  for  the 
experienced  user.  In  addition,  it  is  difficult  to  read  and  know  what  is  actually  being 
specified.  So,  if  it  is  difficult  to  understand  what  the  quay  is  going  to  do,  it  means  the 
language  lacks  ease  of  comprehension  and  will  afiect  not  only  query  readability  but  also 
the  ability  of  the  user  to  specify  the  correct  query. 

(3)  Lack  of  Orthogonality.  “Orthogonality  in  a  programming  langiu^e 
means  that  tiioe  is  a  relatively  small  set  of  primitives  that  can  be  combined  in  a  relatively 
small  number  of  ways  to  build  the  control  and  data  structures  of  the  language.”  [Sebe89] 
[Dates?].  SQL  does  not  provide  the  user  with  a  simple,  clean,  and  consistent  structure.  In 
SQL,  there  are  numerous  examples  of  “arbitrary  restrictions,  exceptions,  and  special  rules.” 
[DatB90b].  An  ex8irq>le  of  an  unorthogonal  construct  in  SQL  is  allowing  only  a  single 
OISINCT  keyword  in  a  SELECT  statonent  at  any  level  of  nesting. 

(4)  Nesting  Construct  SQL  permits  a  nesting  structure  of  the  form: 

SELECT  <attribute  list> 

FROM  <relation  list> 

WHERE  attribute  IN 

(SELECT . ) 

This  format  allows  for  a  block  structure  type  of  construct  The  original  purpose  of 
this  nesting  construct  was  to  allow  the  specification  of  certain  fypes  of  queries  without 
resorting  to  tte  use  of  relational  algebra  or  relational  calculus.  According  to  Codd,  the 
nesting  construct  is  a  part  of  the  **psychological  roix-iqp”  in  SQL.  While  all  queries  that  are 
specified  using  the  nesting  construa  should  be  directly  translatable  into  quoies  using  an 
equi-join  instead,  Ckxkl  shows  that  if  allowing  for  the  existence  of  duplicate  rows  in  tables 
(as  SQL  does),  one  will  come  up  with  a  different  result  when  performing  the  equi-join 
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version  of  the  query  than  when  pafoiming  the  nested  version  [Codd90].  For  detailed 
descriptions  of  SQL  problems,  see  [Qai91]  [Wu91]. 

C.  VISUAL-B ASED  QUERY  LANGUAGES 

Visual  query  languages  allow  the  user  to  visually  specify  a  query  on  the  screen  by 
using  special  gnqrhical  editors.  Here,  visual  means  not  purely  tntuaL  This  kind  of  language 
is  also  know  as  a  graphical  language.  We  can  classify  these  langut^es  into  three  categories 
of  visual-based  query  langnages.  The  first  category  includes  those  which  use  Ziform-based 

representation,  the  second  is  based  on  the  cntity-relationsh4>^  model’s  [Chen76] 
representation,  and  die  third  includes  data  flow  query  languages.  In  this  section  we 
examine  QBE  as  an  example  of  a  form-based  query  language,  DFQL  as  a  data  flow  query 
language,  and  die  ER  model 

L  QBE,  a  Form-based  Query  Language 

QBE  was  developed  roughly  at  the  same  time  as  SQL  during  the  seventies  at 
IBM’s  Laboratory  Research  Centa  (ZlooTT].  Today,  both  languages  arc  available  and 

supported  in  the  Query  Maru^ement  Facility  (QMF)^  offered  by  IBM.  QBE  has  a  user- 

friendly  interfecc.  While  specifying  the  query ,  die  user  does  not  have  to  specify  a  structured 

query  or  text  statement  eiqilicidy  as  in  SQL.  Instead,  the  query  is  formulated  by  filling/ 
piiiring  ^^varioMtsT  in  the  proper  columns  in  forms  of  tables  (reJatimis)  diat  are  di^layed 
cm  the  terminal  screen.  This  means  that  the  user  does  not  have  to  remember  die  name  of 
irfarinma.  Since  operations  ate  speofied  in  die  tabular  from  of  tables,  it  can  be 
said  that  QBE  has  a  *^two-dimensional  syntojT  [Date82]  [Elnui89].  Li  addition,  in  QBE 

2.  Enti^-ielaiioiBh^  litodel » iMiodiKed  by  Chen,  P.  in  1976  as  a  pkaorial  conceptual  de^ 
meihodidogy  for  the  tdadon  model 

3.  The  dialect  of  QBE  supiKxtBd  m  QMF  is  shghtly  difieiem  fioffl  that  iKOixMed  by  ZloQl 
iud  designer  of  QBE  COooTT],  because  QMF  imptemems  QBE  by  iiist  translsiing  it  to  SQL 
PsleiKq.  QMF  is  a  sqiacatB  product  fiom  DB2  and  acts  as  a  query  language  and  lefwct  writer 


there  are  no  rigid  syntax  roles  that  should  be  followed  by  the  user  while  specifying  the 
query  specification.  Instead,  the  user  entos  the  “variables”  as  “constanf"  and  “example' 
values  in  the  proper  colunuis  of  the  forms  to  construct  an  '"example'  of  the  data  for  the 
retrieval  or  update  query.  Like  in  SQL,  this  part  also  enq)hasizes  data  retrieval  queries. 
QBE  is  related  to  the  domain  relational  calculus,  and  its  original  specification  has  been 
shown  to  be  relationally  complete  [Elma89]. 

a.  Data  Retrieval 

As  mentioned  above,  in  order  to  specify  the  quay  for  data  retrieval,  the 
user  should  enter  “example^*  or  “constanf*  values  into  the  proper  columns  in  the  form  of 
tables  (relations).  In  QBE,  the  entering  of  ^example**  values,  usually  preceded  by 
(underscore)  characta,  means  the  exanqtle  value  does  not  have  to  match  qtecific  values  of 
tuples  in  die  database,  so  it  really  represents  the  “free  domain  variable”.  On  the  other  hand, 
“constant”  values  must  be  matched  by  coixesponding  tuple  values  in  the  database.  If  die 
user  is  interested  in  particular  tuple  values,  die  user  types  die  prefix  “P.”  in  that  particular 
column  (attribute).  “P.”  is  used  to  retrieve  a  desired  attribute  value  fiom  a  tiqile  which 
satisfies  die  query,  “P”  standing  for  **prinf\ 


Query  2A:  Example  of  QBE  Query 

Similar  to  SQL,  QBE  also  allows  rdations  to  have  duplicate  tuples.  To 
eliminate  the  diqilicate  tuples  in  the  result  of  a  query,  QBE  uses  the  prefix  “UNQ."  which 
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meuslceq)  rally  unique  tiqiles  in  a  query  result  See  the  query  racample  in  Query  2.4.  The 
English  transhukm  of  the  query  is:  “Retrieve  the  first  name,  last  name,  and  distinct  salary 
of  onployees  who  works  in  projects  “computerization”. 

Rrom  the  example  QBE  query,  it  can  be  determined  that 

•  “ J>x”  is  an  “exanqile”  value  to  join  the  two  tables  by  using  “Dno”  as  a  foreign  key 

•  “Conqraterizatirai”  is  an  actual  “constant”  value,  hi  odier  words,  the  selection 
craidition  using  the  equality  (»)  conqiarison  is  specified  by  entering  directly  a  constant 
value  under  a  proper  column. 

•  “P”  means  to  retrieve  the  attribute  value  for  tiqiles  satisfying  the  query. 


b.  Buili4iipmetionMt  Grouping  and  tdhtr  Operators 

SQL,  QBE  is  also  eqnqqied  widi  built-fbnctions,  such  as  CNT.  (for 
count),  SUM.,  MAX.,  MIN.,  and  AVG.  However,  in  QBE  the  functions  SUM,  CNT.,  and 
AVO.  ate  i^lied  to  **distincf*  values,  die  user  wants  diese  function  to  apply  to  all  values 

desired,  it  should  be  entered  by  using  tte  prefix  “ALL”  1  QBE  provides  a  “G.”  operator  as 

a  grouping  aggr^ate  function.  It  is  analogous  to  the  SQL  GROUP  BY-clause,  and  die 
“condition  box”  in  QBE  is  used  in  die  same  manner  as  die  HA VlNG-clanse  in  SQL.  QBE 
also  uses  die  same  conqiatisrai  operators  as  SQL  exc^  equality  (»).  Therefore,  the  user 
esqplidtly  raitets  die  >,  ^ ,  < ,  ^before  ^ping  a  constant  value.  QBE  also  has  a  negation 
symbol  (-1),  which  is  used  in  a  manner  similar  to  die  NOT  EXISTS  in  SQL,  but  the  same 
effect  can  also  be  obtained  by  using  the  operator.  In  addition,  QBE  also  has  prefixes 
“AO.”  (for  asooiding  order),  and  “I)0.”(for  descending  order),  in  order  to  get  an  ordered 
listed  tuples. 


4.  b  09^  wider  QMF  “AIL”  is  onrdsted  to  the  imivenal  quantifier  |Elina891. 
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c.  TkMPnUmuwUhQBE 

As  mentioiied  above,  QBE  is  very  intuitive,  even  for  novice  users.  It  allows 
the  relatively  inexperiraced  users  to  get  started  in  q)ecifying  single  queries,  even  though 
diey  have  no  prior  knowledge  of  programming  languages.  Unfortunately,  it  becomes  less 
and  less  usdul  as  the  complexity  of  die  queries  increases  and  has  problems  with  more 
complex  queries  [Ozso93]. 

The  expression  of  universal  quantification  in  QBE  as  originally  proposed 
by  Zloof  [ZlooTT]  did  include  support  for  **NOr  EXISTS^,  but  it  was  difficult  and  always 
somewhat  troublesome  [Date90a].  However,  today’s  QBE  that  has  been  released  as  a 
commercial  {voduct  cannot  implement  universal  quantification.  In  fact,  the  QBE  that  we 
discuss  here  (QBE  under  IBM’s  QMF)  provides  no  support  for  universal  or  existential 
quandficatiOT  of  die  f(»m  of  ’’V”  or  *3”.  Thus,  queries  which  involve  universal 
quantificadon  cannot  be  specified  [Date90a]  [Ebiia89]  [Ozso89].  Therefore,  it  is  not 
rthiionatfy  coaifStite. 

2.  DataFlowQiia7LaHinafe(DFQL) 

DFQLis  a  visual/grqdiical  interface  to  reladonal  algebra  based  on  the  dataflow 
paradigm.  It  retains  all  the  c^udnlides  of  current  query  languages  and  is  provided  with  an 
easy  to  use  facility  whidi  extends  die  query  language.  This  extension  allows  the  users  to 
create  new  operators  fixmi  existing  primidve  or  user-defined  operators.  DFQL  includes 
aggregate  funcdons  in  addition  to  the  operators  of  rdadonally  conqilete  query  language.  It 
has  die  power  of  eiqnesaon  beyond  die  benchmarit  of  first  coder  predicate  calculus  by 
providing  die  user  widi  die  ctqiabilides  to  qiecify  universal  and  existoidal  quandficadon. 
(Queries  are  ^ledfied  by  the  user  connecting  the  desired  DFQL  operators  gnqihically  on  dre 
ccMiqmter  scxeea.  The  arguments  for  die  operator  flow  from  the  bottom  or  ’’ouqiut  node”  of 
the  operator  to  the  ttq;>  or  ”iiqnit  node”  of  die  next  operator. 
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a.  DFQL  Operaton 

All  DFQL  operators  have  the  same  basic  appearance  to  enhance  the 

orthogonal!^  of  the  language,  bi  Figure  2.2.  is  a  saiiq>le  operator  (widi  no  name).  It  is 
made  vp  of  three  types  of  components;  the  input  nodeSy  the  body,  and  the  output  node. 

In  DFQL,  the  fimctional  paradigm  is  fully  supported  by  die  DFQL  notation. 
Ibe  iiqirat  to  eadi  qierator,  or  function,  anives  at  die  ii^t  nodes  of  die  operate  and  the 
result  leaves  from  die  ovapat  node.  Therafrne,  aU  of  die  operators  of  DFQL  inqilement 
operatumal  dosuie.  This  means  diat  die  inputs  to  the  operators  are  relations  and  associated 
textual  instructions,  and  die  ouqnit  from  each  operator  is  always  a  relation. 


F%are  2J:  Operator  Constniclioii 


In  fret,  DFQL  (^letatots  can  be  gioiqied  into  two  basic  categories:  pnmitnv 
and  opesatora  Each  primitive  has  a  (me>to-one  coneqptmdoice  with  an  actual 

mediod  in  the  incrementation  language  of  die  interpreter.  User-d^ned  operators  are 
created  fromprirrtitiveqiexatots  and  possibly  odieruser-di^ineti  operators  vdiich  have  been 
previoiisly  created  .  Next,  prbtddve  operators  can  be  broken  down  into  basic,  odier 
prbfitiiyes,  and  dfrplity  operators. 


S.Qnlin|oiialilyiaaprogiaaMBiDglMiguagemeMa  there  is  aidativefynian  set  of  primitives  that 
esn  te  tnariiined  fei  areiaiively  naan  nomber  of  ways  10  build  the  ooneol  snd  data  stractores  of  the 
lii«i^(3dbe891. 
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(1)  Basic  Openuors.  DFQL  provides  six  basic  operators  derived  from  the 
requiremeiit  few  relational  completeness  and  also  the  requirement  to  provide  a  form  of 
grouping  or  aggregation.  Thus,  DFQL  has  the  expressive  poww  of  frrst-orda  predicate 
calculus.  To  be  relationally  complete,  at  least  five  relationai  operators  must  be 
implemeated,  namely  select,  project,  union,  join,  and  d^erence.  See  Table  2.1,  which 
illustrates  dw  basic  DFQL  operattws  and  their  emresponding  translation  in  SQL. 


TABLE  2.1:  BASIC  DFQL  OPERATORS  AND  THEIR  SQL  EQUIVALENTS 


SQL 


rdatioa  condition 


Description  1 

SQL  Equivalent 

Iri^lemeats  the  rdational  algebra 
selection  operamL  The  algebraic 
notation  is: 

^<conditUm>  (<relatioii>). 

It  retrieves  tiq>les  from  die  rdation 
which  fits  the  specified  condition.  There 
are  no  diqilicate  tiqiles  in  the  result 

SELECT  DISTINCT* 
FROM  relation 

WHERE  condidon 

inqilemeitts  die  relational  algriira 
projection  operarer.  The  algebraic 
notatitmis: 

^KmrQmte  H«>(<relation>). 

The  attributes  list  sqiarated  by  commas 
contains  the  names  of  attributes  to  be 
retrieved  from  the  relation  .  The  project 
operator  eliminates  duplicate  tiqiles  from 
die  result 

SELECT  DISTINCT 
attribute  list 
FROMieladon 

TABLE  2.1:  (Continued). 


Description 


Inq[>lements  the  relational  algebra  theta- 
join  operator.  The  algebraic  notation  is: 
<relationl>  Tt<coHdtaon>  <relation2>. 
The  tiqiles  satisfying  tte  condition  are  a 
subset  of  die  titles  of  die  cartesian 
product  If  diere  is  no  condition  input 
the  join  operator  is  “cartesian  product*. 

both  relations  have  the  same  name  for 
an  attribute  which  must  be  used  in  the 
condition,  use  to  right  order  of 
rdations  coming  into  the  operator  (e.g. 
rl.ssn  « t2.essn),  where  ssn  and  essn  are 
primary  keys  or  ftneign  keys  of  relationl 
and  tdation2  reflectively. 


SQL  Equivalent 


SELECT  DISTINCT* 
FROM  leiatitml  rl, 
ielati(ni2i2 
WHERE  condition 


Inqdements  die  relational  algebra, 
d^S/ierence  operation.  The  algebraic 
notatumis: 

<elationl>  -  <rdati(»i2>. 

Relational  difference  returns  as  a  result  a 
relation  diat  contains  all  the  tiqiles  duit 
occur  in  <rdationl>  but  not  in 
<cdation2>.  d^f  requires  dut  both 
relations  be  union  compatible. 


SELECT  DISnNCT* 
FRmi  idationl 
MINUS 

SELECT  DISTINCT* 
FR(Mf  idationZ 


TABLE  2.1:  (Continued). 


DFQL 

Dc9cri|Rion  j 

SQL  Equivalent 

idaiiQfil  rdation2 

Tr 

— r — 

UNION 

In^tements  the  relational  algebra  union 
q)eration.  The  algebraic  notation  is: 
oelation  1>  u  <relation2>. 

This  operator  takes  all  the  tuples  from 
both  relations  and  combines  them, 
duplicate  tuples  being  eliminated.  Union 
requires  both  relations  to  be  union 
compatible.  This  restriction  is  necessary 
since  union  does  not  create  additional 
columns  for  Ae  ouqiut  relation. 

SELECT  DISTINCT* 
FRCAf  leJationall 

UNION 

SELECT  DISTINCT  * 
FROMielatioiiaI2 

v/Mil 

GroupCnt  (a  short  hand  for  group  count) 
is  defined  as  a  basic  operatm  in  order  to 
provide  the  user  with  some  simple 
aggregation  capabilities.  It  provides  die 
user  a  means  to  formulate  queries  that 
involve  universal  quantification. 

GmupCnt  requires  a  relation,  a  list  of 
groiqiing  attributBS,  and  an  alias  name 
for  die  result  Qtouping  attributes  can  be 
more  dum  one  attrftute,  si^arated  by 
ctmunas.  The  count  result  is  an  integer 
uiiich  gives  die  total  number  of  tuples  in 
diat  grouping. 

SELECT  DISTINCT 
grouping  attributes, 
COUNIX*)  count  attt 
FROMielatkm 

GROUP BY 
grouping  utributBS 

mam 

( gro^JCnt ) 

GROUP  CNT 
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(2)  OAcr  Primitives  Operators.  DFQL  provides  several  other  primitive 
operators  to  perform  special  operadons  on  relations.  Most  of  these  additional  primitives 
perform  operations  at  such  a  low  level  that  the  user  would  not  be  able  to  specify  them  as  a 
user-d^ned  operator.  However,  all  of  these  additional  operators  could  also  be  specified  as 
user-defined  operators  as  welL  To  illustrate,  see  Table  2.2.  which  lists  these  other  primitive 
operators  and  their  conresponding  translation  into  SQL. 


TABLE  2,2:  NON-BASIC  DFQL  OPERATORS  AND  THEIR  SQL  EQUIVALENTS 


SQL 

Desoription 

SQL  Equivalent  | 

lelationl  lB]atifi02 

Inqtlements  relational  algebra 

intersection  operation.  The  algebraic 
notation  is: 

<telationl>  n  <telation2>. 

R  returns  die  titles  which  exist  in  both 
relations,  as  a  result  out  relation. 
Intersect  requires  bodi  relations  to  be 
muon  corrqpatible.  The  inqilementation 
of  intersect  is  identical  to  union  and  tfgf 
operators. 

SELECT  DISTINCT  • 
FROM  relationl 
INTERSECT 

SELECT  DISTINCT* 
FROMielation2 

yr 

( intersect) 

' — -tr - ' 

INTERSECT 

grouping  attributes 

Finds  the  minimum  value  of  the 
^lecified  attribute  in  separated  sections 
according  to  the  grouping  attributes.  It 
gives  tte  grouping  attribotes  and 
produces  the  minimum  values  of  each 
group  in  a  column  named  widi  the  given 
alias  name  as  aresnlt  of  relation. 

SELECT  DISTINCT 
gioiqniig  attributes, 

MIN  (aggr.  attr) 

FROM  relation 

GROUP BY 
groiqnng  attributes 

' - 

aggregate  attE. 

\It 

(SOUP  MIN 
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TABLE  2J2:  (Continued). 


Description 


SQL  Equivalent 


Similar  to  groupMin  except  it  finds  the 
maximum  value  of  the  aggregate 
attributes  according  to  the  grouping 
attribute. 


SELECT  DISTINCT 
grouping  attributes, 
MAX(aggr.  ^.) 
FROM  relation 
GROUP  BY  group  attr. 


Similar  to  the  previous  operator,  excq>t 
it  finds  the  total  value  of  all  the  aggregate 
attribute’s  values  according  to  the 
grouping  attributes. 


SELECT  DISTINCT 
grouping  attributes, 
SUM  (aggr.  attr.) 
FROM  relation 
GROUP BY 
grouping  attributes. 


As  previous  operators,  excqri  it  finds  the  SELECT  DISTINCT 
^  average  value  of  the  aggregate  attributes  grouping  attributes, 

—  according  to  the  grouping  attributes.  C**®*’-  ****’•) 

FROM  relation 


FROM  relation 
GROUP BY 
grruping  attributes. 


27 


TABLE  12:  (Continued). 


GROUP  ALL  SATISFY 


It  is  a  sinqtle  way  of  introducing  It  can  be  translated  into 
universal  quantification.  It  takes  a  a  sequence  of  SQL 
relation  and  splits  the  tuples  according  to  statemoits. 
the  grouping  attribute  list  and  then 
checks  aU  tuples  in  individual  groups 
according  to  the  condition  specified.  If 
all  the  tuples  satisfy  the  condition  then 
an  ouq)Ut  tuple  value  is  generated 
consisting  of  the  grouping  attribute  list 
So,  it  means  that  this  group  satisfies  the 
condition  in  all  tleir  tuples. 

j _ 


This  operator  is  the  opposite  of  It  can  be  translated  into 
groupAUSatufy  operator.  It  gives  the  a  sequence  of  SQL 
grouping  attributes  only  if  none  of  the 
tuples  satisfies  the  condition. 


CTOUPNONE  SATISPy 


GROUPN  SATISFY 


It  is  closely  related  to  groupAllSad^. 
The  only  di^fetence  is  that  groiqiNSati^ 
takes  an  extra  input  which  allows  the 
user  to  specify  ex^y  how  many  of  the 
tuples  in  the  group  need  to  satisfy  the 
givoi  condition  in  order  for  that  groiq)  to 
be  included  in  the  resulting  relation.  So, 
the  fourth  argument  {number)^  must 
consist  of  one  of  the  operators  (<,>,  =  < 
s,  >  s, !»)  and  a  number. 


It  can  be  translated  into 
a  sequence  of  SQL 
statements. 


(3)  Display  Operators.  The  display  operators  are  provided  to  allow  the 
user  to  print  the  contents  of  a  relation  on  the  computer  screoi.  The  most  common  usage  is 
to  print  out  the  final  result  of  a  query.  There  are  two  display  operators: 

•  display.  It  talces  as  inputs  a  relation  and  a  text  string  to  be  used  as  a  tide.  The  tide 
makes  it  easy  to  differentiate  between  printed  results  when  more  than  one  display 
operator  is  u^  in  a  query. 

•  sdisplay.  It  is  used  to  produce  a  sorted  printout  of  a  reladon.  Each  attribute  in  the  list 
may  be  followed  by  “ASC’  (ascending)  or  “DESC’  (descending). 

(4)  User-defined  Operators.  These  kinds  of  operators  give  die  flexibility 
to  the  user  to  define  his/her  own  style  of  operator  and  extend  the  capability  of  the  language 
according  to  his/her  desires.  With  user-defined  operators,  the  user  can  constract  his  own 
operators  diat  look  and  behave  exacdy  like  tlw  primitive  operators  provided  in  DFQL.  The 
user  can  (xetde  operators  for  situations  that  are  unique  to  his  query  needs.  This  kind  of 
flexibiliQr  is  gained  without  a  loss  of  the  power  of  orthogonality,  since  user-defined 
(iterators  are  constructed  by  combining  the  available  primitives  with  previously  defined 
user  operators  as  well 

(5)  DFQL  (Juery  Construction.  General  ideas  behind  DFQL  construction 
have  been  impliddy  discussed.  (Juery  constructions  will  be  presented  in  Ch^ter  IH  All 
DFQL  queries  exist  as  data  flow  programs  in  which  text  objects  and  operators  are 
connected  to  each  other  by  lines  called  data  flow  paths  and  all  of  the  information  traverse 
these  paths  during  execution.  DFQL  objects,  except  operations,  do  not  have  any  input 
nodes  and  can  be  executed  anytime.  They  pass  the  relation  object,  attribute  list,  or  condition 
in  order  to  be  used  by  an  operator.  As  soon  as  all  the  input  nodes  have  the  information,  the 
operator  can  be  executed  and  produces  a  relation  at  its  ouq>ut  node.  Since  a  DFQL  query 
does  not  permit  iteration  and  recursion,  however,  execution  of  the  query  can  be  visualized 
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as  flowing  ftom  the  top  the  diagram  to  the  bottom.  There  is  no  restriction  on  how  operators 
are  placed  on  the  screen;  top-down  placement  is  recommended  for  readability. 

(6)  Incremental  Queties.This  is  the  most  important  feature  provided  by 
DFQL.  It  allows  the  user  to  specify  or  create  his/her  queries  incrementally.  In  other  words, 
die  user  can  formulate  one  portion  of  the  query,  and  then  check  the  Results  (returns  back  if 
needed),  and  continue  to  build/create  other  portions  of  the  query  one  by  one.  This  usability 
gives  more  flexibility  to  the  user  during  his/her  work,  especially  when  creating  a  complex 
query.  It  helps  the  user  prevent  losing  track  of  what  he/she  is  doing  and  provides 
intermediate  results  to  he4)  in  query  constmction.  Specifically,  this  feature  can  be  divided 
into  two  sections,  namely  incremental  construction  and  incremental  execution. 

•  Incremental  Construction.  This  provides  the  user  with  the  capability  to  specify/aeate 
die  query  part  by  part,  which  is  ncxeatingly  helpfiil  as  the  complexity  of  the  query 
increases. 

«  hicremental  ExecutiomThis  feature  is  hdpfiil  during  the  debugging  of  coiiqilex 
queries.  If  a  complete  query  does  not  produce  a  desired  result,  it  allows  the  user  to 
check  level  by  level  in  order  to  find  die  erroneous  part  and  fix  it  Therefore,  the  user 
can  see  the  intermediate  result  at  any  level  by  executing  the  query  incrementally. 

(7)  Universal  (Quantification.  The  problem  of  expressing  universal 
quantification  in  existing  query  languages  has  been  discussed  in  previous  section.  DFQL 
provides  a  unique  solution  to  this  problem,  by  implementing  sinqile  counting  logic  to 
achieve  the  result  that  fulfill  the  requirements  of  universal  quantification.  The  basic  idea 
employed  is  that  if  all  tuples  in  a  relation  or  a  group  must  satisfy  some  criteria,  the  number 
of  tiqiles  diat  meet  the  criteria  ate  counted  and  then  con^ared  to  the  total  number  of  tiqiles 
under  consideration,  if  these  two  numbers  are  equal,  then  the  universal  quantifier  has  been 
satisfied.  In  DFQL,  the  operators  that  can  implonent  universal  quantification  are: 
grotqtAUSatittfy,  groupNoneSati^,  and  groupNSatisfy  operators.  However,  the  users  can 
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achieve  universal  quantification  as  well  by  building  their  own  quantifications  as  a  user- 
defined  operaun  using  the  primitive  operators. 

(8)  Nesting  and  Functionai  Notation.  The  nesting  feature  of  SQL  exists 
naturally  in  DFQL.  As  discussed  before,  one  by  one  execution  of  operators  to  supply  input 
data  to  odier  operator  is  like  block  structured  execution  in  SQL  from  the  “inside”  to  the 
“outside”  of  nesting  queries.  The  lack  of  specific  nesting  structures  in  DFQL  improves  the 
readability  and  orthogonality  of  the  language.  The  use  of  functional  notation  for  all  of  the 
DF(^  operators  greatly  enhances  orthogonality.  Relational  operational  closure  is 
implemented  by  the  functional  paradigm.  The  use  of  operators  that  may  take  more  than  one 
input  but  produce  only  one  output  allows  for  their  easy  combination  into  user-defined 
operators  as  discussed  before. 

(9)  Orapbicai  Structure  of  DFQL  Query.  DFQL*  s  visual  representation  of 
die  query  is  a  data  flow  graph  consisting  of  DFQL  objects  which  are  connected  together 
by  lines  of  data  flow  paths.  As  such,  the  graphical  structure  r^resents  the  relational 
algebra  sfructure  for  execution  of  the  query.  By  using  a  graphical  relational  algebra 
iqtproach  to  query  formulation,  it  provides  a  much  more  consistent  and  straight  forward 
interfru:e  to  the  databases. 

3.  Entity-Rdationship  Model  Interface 

The  Entity-  Relationship  (ER)  modd  was  introduced  in  [Chen76].  The  ER  model 
has  been  used  extensively  as  a  high-level  conceptual  data  model  The  main  idea  behind  diis 
model  is  to  illustrate  the  concepts  of  entity  types  and  relationships  betweoi  entity  types  in 
a  graphical  way  in  order  to  enhance  understanding  of  the  structure  desire  for  a  database.  An 
example  of  visual  representation  of  the  ER  model  is  shown  in  Figure  2.3. 
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Figure  13:  ER  schema  diagram  of  the  COMPANY  database  [Elma89] 


Prom  the  ER  diagram  we  can  illustrate  that: 

•  TTic  entity  types  such  as  EMPLOYEEE,  DEPARTMENT,  and  PROJECT  are 
represented  as  rectangular  boxes. 

•  Relationship  types  such  as  WORKS_FOR,  MANAGES,  CONTROLS,  and 
WORKS.ON  ate  rqttesented  as  diamond-shape  boxes  that  are  attached  to  the 
participating  entity  types  with  straight  lines. 

•  Both  entity  types  and  relationship  types  have  attributes  which  are  represented  by  the 
oval  circles  where  each  attribute  is  attached  to  its  entity  type  or  relationship  type  by 
a  straight  line. 
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•  **Naine”  is  an  attribute  of  EMPLOYEE  and  has  composite  attributes  such  as  Fname, 
Minit,  and  Lname. 

•  Location  in  double  avals  represents  multivalued  attributes,  and  dotted  ovals  represent 
derived  attributes. 

•  attributes  have  dieir  names  iMd^riined 

•  Double  rectangles  represent  a  uvoi^e/triry,  where  the  weak  entiQr  means  an  oitityQqre 
which  may  not  have  any  key  attributes,  and  the  double  diamond  as  the  identifying 
relationshfy. 

•  The  partial  key  of  the  weak  entify  type  is  underlined  with  dotted  line. 

•  The  particqtation  constraint  is  specified  by  a  single  line  for  partial  participation,  with 
the  cardinality  ratio  is  attached;  a  doable  line  illustrates  total  partidpatioiL  For 
exanqde,  die  particqiation  of  EMPLOYEE  in  WORKS_FOR  is  total  (every  employee 
must  woik  for  a  dqiartment),  while  tlw  participation  of  EMPLOYEE  in  MANAGES 
is  partial  (not  every  employee  manages  a  department).  [Elma89] 

Hie  idea  of  using  die  ER  diagram  as  a  query  language  is  to  let  the  usa  not  wony 
about  the  particular  Join  conditions  between  entity  fypes,  however,  it  tends  to  force  the  user 
to  rely  on  the  specified  relationships.  These  relationships  are  all  diqilayed  to  the  user.  This 
can  be  a  benefit  to  a  novice  user,  who  does  not  really  understand  how  the  data  in  the 
database  fits  togedier;  but  it  seems  somewhat  fataL  to  write  queries  which  depend  on 
relationshfys  that  the  user  may  not  fully  understand.  The  ability  to  use  a  relationship 
widiout  knowing  how  it  is  actually  set  up  increases  the  chance  of  syntactically  correct 
queries  that  will  produce  the  wrong  resulL  The  ER  model  as  mentioned  above  does  not 
affect  our  next  discussion.  It  is  presented  in  order  to  illustrate  features  of  another  visual- 
based  query  language  that  are  also  available  for  RDBMS’s. 
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UL  THE  COMPARISON  OF  SQL,  QBE  AND  DPQL  WITH  RESPECT 
TO  DATA  RETRIEVAL  CAPABILITIES 


Hist  of  all,  we  consider  that  the  notion  of  a  query  language  as  a  high  level  language 
means  it  is  intended  to  be  used  by  a  iKm-progtammer  or  a  user  without  specialized  training. 
However,  as  mentioned  in  two  previous  chapters,  the  user  faces  some  difficulties  in 
specifying  correct  queries,  especially  as  they  relate  to  universal  quantification  and  nesting 
in  SQL,  and  universal  quantification  in  QBE.  Then,  we  attempt  to  observe  how  DFQL 
overcomes  the  [»oblems  that  are  encountered  by  SQL  and  QBE. 

This  chapter  focuses  on  the  comparison  of  SQL,  QBE,  and  DFQL.  In  order  to 
accomplish  the  comparison  of  these  three  languages,  numerous  queries  are  composed  by 
categcay,  in  which  each  language  is  specified  and  compared.  Some  of  the  queries  are  stand¬ 
alone,  but  some  others  specified  are  logical  extensions  (or  the  complexity  is  increased) 
from  <Mie  query  to  the  next  Such  extension  types  of  queries  are  chosen  to  analyze  the  query 
language’s  ease-of-use,  flexibility,  and  omsistency  in  formulating  logically  related  queries 
with  respect  to  data  retrieval  for  RDBMS's.  Consider  the  following,  brief  explanation: 

•  Ease-of-use  particularly  emphasizes  how  easy  the  query  language  is  to  learn  and 
express  queries  in. 

•  FtexibiUty  means  more  than  one  way  of  expressing  a  single  query. 

•  Consistency  means  similar  thinking  in  a  mental  model  can  be  expressed  in  a  similar 
structure  in  the  language. 

All  the  rejnesentative  set  of  queries  presented  are  matched  to  the  taUes  of  a  relational 
database  instance  of  the  COMPANY  schema  which  are  provided  in  Appendix  A.  Some  of 
the  queries  are  related  to  queries  that  are  presented  in  [Elma89].  Based  on  the  above,  this 
diapter  is  divided  into  two  sections:  first  the  categories  of  the  queries,  and  second  is  the 
analysis  oS  the  strengths  and  weaknesses  of  the  comparison  of  all  three  languages. 
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A.  CATEGORIES  OF  QUERY 

In  order  to  compare  these  three  languages,  numerous  queries  are  composed  by 
category.  The  queries  are  divided  into  four  categories;  single-value,  set-value,  statistical 
result,  and  set-count  value.  In  each  categtxy  SQL,  QBE,  and  DFQL  are  specified  and 
compared. 

1.  Single-Value 

In  this  category  the  user  (end  user)  attempts  to  obtain  a  proper  relation  of  a 
relation  (table),  based  on  a  single-value  expression.  As  a  result  of  the  single  value 
expression  in  the  queries,  the  user  can  expect  to  obtain  a  table,  a  single  colunm,  a  single 
row,  or  a  single  scalar  value.  These  correspond  to  a  constant  value  d*  table-expression, 
column-expression,  row-expression  and  scalar-expression,  respectively,  in  a  relation.  A 
scalar-expression  is  a  special  case  of  a  row-expression  and  a  special  case  o(  a  column- 
esqxvssion  [Date83].  The  null  value  in  this  case  is  also  presented  as  single  value  (see 
Chq)terII.A). 

In  this  category,  the  qjerators  such  as  “=”,  “or”,  “>”,  and  “fife",  are 

generally  used  in  the  relation-t^ration,  Init  we  can  also  perform  the  standard  arithmetic 
opoattxs  “+”,  and  “r.  In  addition,  if  we  are  concerned  with  a  single  scalar  valiw, 

a  set  of  special  aggregate  functions  such  as  COUNT,  SUM,  AVG,  MIN  and  MAX  can  also 
be  applied.  In  this  research  these  aggregate  functions  fall  under  the  statistical-result 
category.  Ccmsider  the  following  queries: 
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a.  Qtury  I  :Simplg  retrieval 


List  the  salary  of  every  employee. 

(1)  SQL 

SELECT  SALARY  -  SELECT  SALARY 

fhom  employee  from  employee 

WHERE  TRUE  =  TRUE 

Since  in  the  WHERE-clause  we  can  specify  TRUE  =  TRUE,  the 
above  query  can  be  considered  single  value.  It  yields  a  single  ct^umn  to  be  a  new  relation. 
If  there  are  multiple  employees  with  the  same  salary,  that  salary  will  be  disfdayed  multifde 
times  as  redundant  duplicate  tuples  in  the  result  of  the  query.  If  we  are  concerned  with 
distinct  values.  SQL  allows  us  to  use  the  keyword  DISTINCT  in  the  SELECT-clause; 

SELECT  DISTINCT  SALARY 

FROM  EMPLOYEE 

The  results  of  these  two  alternative  qumes  are: 

Without  keyword  DISTINCT  With  keyword  DISTINCT 


(2)  QBE 


BMnjQYBB 


LNAME 

SL 

BOAIE 

ADDRESS 

SEX 

SALARY 

P._Sx 

Since  we  are  interested  in  retrieving  the  SALARY  values,  in  QBE 
"P.JSx"  is  placed  in  the  column  of  the  SALARY  attribute.  As  discussed  in  Chapter  II.  the 
preflx  “P**  is  used  to  indicate  that  the  values  of  the  SALARY  column  are  to  be  retrieved. 
General  speaking,  QBE  allows  the  user  just  to  specify  “P.”  instead  of  “P._Sx”.  In  other 
words,  QBE  retrieves  the  same  thing.  This  seems  very  simile  to  specify.  However,  in  s(xne 
cases  QBE  also  allows  redundant  duplicate  tuples  to  exist  in  the  result  In  order  to  avcxd 
redundant  tu{des,  the  prefix  “UNQ.”  is  needed  as  an  operator  since  it  keeps  only  unique 
xi^Ats  in  a  queiy  result  Tho^ore,  if  we  are  concerned  with  distinct  values,  the  "P._5x" 
from  die  above  queiy  can  be  rei^aced  by  **P.  UNQ.JSx*'.  The  results  are  the  same  as  for  the 
SQL  queiy  above. 

(3)  DPQL 


The  attribute  list  Salaiy  is  to  be  retrieved  frc«n  the  EMPLOYEE 
relation.  The  result  of  the  {xojection  is  displayed  on  the  screen  by  display  operator.  The 


result  is  a  proper  relation  which  contains  <Mily  the  values  from  the  column  of  the  specified 
attribute  Salary.  Here,  the  project  operator  eliminates  the  redundant  duplicate  tuples  of  the 
attribute.  The  result  is  the  same  as  the  SQL  query  using  the  DISTINCT  curator  in  '‘a.(l)*’ 
above. 

b.  Query  2:  Quai^ted  retrieval 

List  all  employees  whose  salary  is  more  than  $50,000. 

(1)  SQL 

SELECT  * 

FROM  EMPLOYEE 
WHERE  SALARY  >50000 

The  asterisk  (*)  in  the  SELECT-clause  is  shrathand  for  retrieving  all 
the  attribute  values,  in  order,  of  tu{des  satisfying  the  query.  The  tuple  selected  must  satisfy 
the  conditicm  **SALARY  >50000”.  Since  die  query  is  asking  for  the  list  of  all  employees 
who  fulfil  the  condititm,  the  asterisk  character  should  be  used  in  SELECT-clause.  The 
SELECT-clause  retrieves  all  the  employee  attributes  of  tui^es  from  the  EMPLOYEE 
reiaticm  that  satisfy  the  condition  specified.  There  are  no  redundant  tuples  in  the  result 

(7)  QBE 


The  “>50000"  is  specified  in  order  to  get  the  tuples  that  satisfy  the 
condititm  “>  50000”,  where  “50000”  is  as  an  actual  constant  value.  Placing  the  “P."  below 
the  rdation  name  means  to  retrieve  all  the  attribute  values  d  tuples  of  the  relation  which 
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match  the  conditicm  specified.  Since  the  key  attribute  is  included  in  all  tuples  returned, 
there  are  no  chiplicate  tuples  in  the  result 


(3)  DPQL 


EMPLOYEE  Salani  >  50000 


By  using  the  select  r^rator,  the  query  retrieves  tuples  from  the 
EMPI-OYEE  relation  which  meet  the  specific  condition  Salary  >50000.  There  is  no 
alteration  in  the  structure  of  the  relation,  so  there  are  no  redundant  tuples  in  the  query  result 


The  result  of  the  Query  2  is: 


BDA1E 

SEX 

SALAJOr 

DNO 

E 

Borg 

88866555 

lO.Nw-27 

450  Stone,  Houfton,  ITC 

M 

ssooo 

miU 

1 
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c.  Qiury  3:  Retrieval  invtUvet  more  than  two  tablea 


For  every  project  located  in  Houston,  list  the  project  name,  the 
ctmtrdUing  (tepaitment  number,  and  department  manager's  last  name,  ssn,  and  sex. 

(1)  SQL 

SELECT  PNAME,  DNUM,  LNAME,  SSN,  SEX 
FROM  EMPLOYEE,  DEPARTMENT,  PROJECT 
WHERE  MORSSN  =  SSN  AND  DNUM  =  DNUMBER 
AND  PLOCATION  =  ‘Houston’ 

This  query  is  select-project-join  with  two  join  conditions.  The  join 
condititm  is  specified  according  to  the  key  and  the  foreign  key  of  the  relations.  Here  we 
specify  DNUM  s  DNUMBER  as  the  join  ccmdition  regarding  the  controlling  department 
<rf  a  project,  while  the  MGRSSN  =  SSN  joins  the  controlling  department  to  the  employee 
who  mana^  the  department  PLOCATION  =  ‘Houston’  specifically  specifies  projects 
that  are  located  in  Houston. 

(9  QBE 


EMPLOVEB 


fMAMB 


MtNTT 


LNAME 


BOAIE 


AI»»ESS 


SEX 


SALARY 


SUFERSSN 


1X40 


P. 


E_Sx 


P. 


CEPARIMENT 

MORSSN 

MGRSTARTDAIE 

j»t 

_Sx 

PROJECT 

PNAME 

PLOCATIOI 

DNUM 

P. 

Houston 

P.J3X 

In  this  query  an  example  variable  “.Sx”  is  used  to  join  relations 
EMPLOYEE  and  the  DEPARTMENT  at  the  key  and  foreign  key.  “.Dx”  is  used  to  relate 
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the  key  and  foreign  key  of  the  joined  relations  DEPARTMENT  and  PRC3JECT.  “P.”  is  used 
to  retrieve  the  attribute  values  of  joined  tuples  that  fulfil  the  condition 
PROJECT.PIjOCATION  =  “Houston”. 

(3)  DFQL 

PROJECT  Ploeatloa  «  Heusteo 


The  select  curator  will  select  the  projects  that  are  located  in  Houston 
fnm  the  PROJECT  relaticML  The  result  at  the  select  operalcM’  output  retains  all  the  attributes 
of  each  selected  project  tuple,  assuming  it  is  as  a  new  relation  rl  (a  subset  of  PROJECT 
relaticm).  The  rl  is  joined  with  the  DEPARTMENT  relation  by  emi^oying  the  join  operates’ 
with  the  equi-join  condition  rl.  Dnum  =  i2.  Dnumber  in  order  to  get  the  controlling 
dqraitment  The  result  is  used  by  the  next  join  operatm*,  with  the  equi-join  condition 
mgrssn  s  ssn  relating  the  employee  who  manages  the  department  Each  join  opexutor 
produces  a  cartesian  product  of  all  the  possiNe  tuples  of  both  incoming  relations  based  on 
the  join  condition.  This  result  is  then  used  by  the  following  operator.  Bnally  the  project 
opesstat  produces  the  desired  relation  result  with  values  from  the  attribute  list 
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The  result  of  Query  3  is: 


PNAME 

DNUM 

LKAME 

SSN 

SEX 

ProductZ 

5 

Wong 

333445555 

M 

Reotgaaizati(xi 

1 

Borg 

888665555 

M 

d.  Query  4:  Retrieval  involving  universal  quantification 

Retrieve  the  department  number  where  all  of  its  employees  have  salaries  of 
more  than  $40,000. 

(1)  SQL 

SELECT  DNO 
FROM  EMPLOYEE  E 
WHERE  NOT  EXISTS 
SELECT  * 

FROM  EMPLOYEE  El 
WHERE  E  DNO  -  El.  DNO 

AND  SALARY  s  40000) 

This  query  involves  one  nested  query  which  selects  all  the 
EMPLOYEE  tuples  related  to  an  EMFTjOYEE  relation  itself.  SQL  in  diis  case  implements 
a  NOT  EXISTS  operator  in  order  to  express  universal  quantifier  in  the  WHERE-clause  by 
use  of  a  negative  logic.  The  nested  query  checks  all  the  EMPLOYEE  (El)  tuples  according 
to  the  condition  specified,  such  that  none  of  the  employee  tuples  satisfies  the  condition, 
then  the  EMPLOYEE  (E)  tuple  is  selected.  If  we  rephrase  the  query,  it  becomes  “retrieve 
the  department  number  if  there  does  not  exist  any  employee  with  the  department  number 
who  has  a  salary  less  than  $40,000”.  Notice  the  use  of  "E”  and  “El”  as  aliases  for  the 
EMPLOYEE  relation.  In  this  case  “E”  and  “El”  represent  two  different  copies  of 
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copies  of  EMPLOYEE  relations.  Each  DNO  will  be  duplicated  if  the  department  has  more 
than  one  employee.  This  can  be  avoided  by  using  DISTINCT. 


(2)  QBE.  As  discussed  in  Chapter  II,  QBE  lacks  the  existential  and 
universal  quantification  expressions.  Therefore  this  kind  of  query  cannot  be  specified. 

(3)  DFQL 


As  discussed  in  chapter  II,  DFQL  provides  the  user  some  group 
(Aggregate  functions  that  can  be  used  to  express  the  query  that  contains  universal 
quantification.  One  possibility  is  specified  just  by  employing  the  groupAUSatisfy.  It  takes 
the  EMPLOYEE  relation  and  checks  all  the  tuples  in  each  group  of  department  number 
“Dno”  that  satisfies  the  condition  Salary  >  40000. 

The  result  of  Query  4  is;  none 
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e.  Query  5:  Retrieval  involvii^  a  negation  etutement 


For  each  department  retrieve  the  first  names  and  the  last  names  of  employees 
who  have  no  dependents. 

(1)  SQL 

SELECT  DNOFNAME.LNAME 

FROM  EMPLOYEE 

WHERE  NOT  EXISTS  (SELECT* 

FROM  DEPENDENT 
WHER  SSN=rESSN) 

GROUP  BY  DNO 

The  nested  query  retrieves  all  DEI^NDENT  tuples  related  to  the 
EMPLOYEE  tuple.  As  in  Query  4,  this  query  also  uses  the  NOT  BASTS  opeiator.The 
nested  query  checks  all  the  DEPENDENT  tuples  to  see  if  the  ESSN  is  the  same  as  the  SSN 
(rf*  die  current  EMPLOYEE  tuide.  If  n<me  match  the  nested  query  returns  an  empty  reladon 
since  there  are  no  dependents  associated  with  the  current  emidoyee.  Therefore,  the  desired 
attributes  of  the  tuple  are  selected. 

(9  QBE 


SSN 

R 

p. 

_Sx 

BDAIE 

ADDRESS 

M 

SALARY 

Dm 

G. 

iUi252S3li 

ESSN 

SBC 

BDATB 

RELATIONSHIP 

■n 

_Sx 

By  looking  at  this  query,  we  notice  that  QBE  has  a  negation  symbol 
(-•).  In  this  case  the  negation  symbol  “  is  used  in  a  way  similar  to  the  NOT  EXIST 
function  of  SQL.  It  will  join  tuples  of  relations  EMPLOYEE  and  DO*ENDENT  if  their 
values  of  “_Sx”  do  not  match  each  other.  However,  the  query  can  also  be  specified  by 
placing  a  in  the  ESSN  column,  producing  the  same  result  [Elma89]. 

(3)  DFQL 


l>EPEIIIDEIiT 


DFQL  provides  the  groupNoneSatisfy  operator  which  can  be  used  to 
specify  this  kind  of  query.  First,  we  jdn  both  relations  EMPLOYEE  and  DEPARTMENT, 
which  results  in  the  cartesian  product  as  an  input  to  the  groupNoneSatisfy  operator.  The 
groupNoneSatisfy  takes  the  tuples  according  to  the  grouping  attribute  essn  and  checks  to 
see  if  none  of  the  tuples  satisfies  the  condition  ssn  ==  essn.  If  so,  the  project  operator  will 
project  the  first  name  and  last  ruune  oS  the  employee. 
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In  DPQL  this  query  can  also  be  specified  by  using  the  diff  operator.  In 
the  fcdlowing  query,  the  inputs  to  the  operator  arc  the  results  of  two  project  operators, 
say  left  and  right  side.  The  left  side  result  holds  the  ssn  all  of  the  employee  in  rl,  while  the 
right  side  hcdds  the  ssn  of  employees  who  have  dependents  in  result  r2.  The  diff  operator 
diecks  these  two  relations  rl  and  r2,  and  returns  any  ssn(s)  which  do  not  appear  in  both  rl 
and  i2  as  the  result,  i.e.,  the  ssn  of  employees  who  do  not  have  dependents. 


The  result  of  Query  S  is: 


Blame 

Lname 

Alicia 

Zelaya 

Runesh 

Narayan 

Joyce 

Rngliah 

Ahmad 

Jabbar 

Jamesh 

Borg 
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2.  Set-Value 

In  this  categoiy  the  user  (end  user)  tries  to  obtain  a  proper  relation  from  one  or 
more  relaticm  based  on  the  set-value-ex{Hession  that  correspond  to  a  constant-set  of  query 
specificaticms.  In  this  categcny,  the  set  operations  such  as  union,  difference  (minus),  and 
intersection  can  also  be  applied.  Consider  the  following  queries: 

A  Query  6:  Retrieval  involving  existential  and  universal  quantification 
Retrieve  the  department  names,  first  names,  and  last  names  where  all  of  its 
employees  have  salaries  oi  more  than  $40,000  and  have  no  dependents. 

(1)  SQL 

SELECT  DNAME,  FNAME,  LNAME 

FROM  DEPARTMENT  D.  EMPLOYEE  El 

WHERE  D.  NUMBERS E  DNO 

AND  NOT  EXISTS  (SELECT  * 

FROM  EMPLOYEE  E2 
WHERE  D.DNUMBER  =  E2.DNO 
AND  (SALARY  s  40000 
OR  EXISTS 
(SELECT  * 

FROM  DEPENDENT 
WHERE  SSN  =  ESSN))) 

GROUP BY  DNAME 

This  query  is  an  extension  of  Query  4  or  like  a  combination  of  Query 
4  and  Query  5.  SQL  specifies  this  query  by  employing  the  EXISTS  and  NOT  EXISTS 
operators  with  two  nested  queries.  The  existential  quantification  is  specified  by  the 
EXISTS  (^ratce  in  the  nested  select  statement  and  universal  quantification  is  expressed 
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by  using  the  NOT  EXISTS  operator.  Therefrae,  a  rephrasing  would  be  “retrieve  the  name 
of  departments  togedier  with  their  employee’s  first  and  last  names  such  that  there  does  not 
exist  any  employee  whose  salary  is  less  than  or  equal  to  $40,000  or  who  has  at  least  one 
depenttent”.  In  order  to  specify  this  query,  in  SQL  we  caimot  combine  Query  4  and  Query 
5  without  rewriting  oc  specifying  a  new  query  structure. 

(2)  QBE  As  discussed  in  Chapter  II,  QBE  lacks  the  existential  and 
universal  quantification  expressions.  Therefore,  this  kind  of  query  cannot  be  specified. 

(3)  DPQL 


By  looking  at  this  query,  we  recognize  this  query  as  a  combination  of 
Query  4  as  the  “X”  part  of  the  query  and  “Y”  as  the  main  part  of  Query  5.  The  intersect 
optmtoc  takes  two  relations  which  are  union  compatible  (rl  and  s2)  and  returns  as  a  result 
(i3)  the  tuples  which  are  in  both.  Then,  by  emi^oying  the  Join  operator,  we  join  r3  with  the 
DEPARTMENT  relation  (r4)  based  on  the  aqui>join  condidtm  r3.  Dnum  =  r4.  Dnumbm*. 
The  result  is  a  subset  of  the  cartesian  product  erf*  i3  and  r4  and  becomes  an  input  to  the 
project  operator. 


The  result  of  Query  6  is: 


Dname 

Foasae 

Lname 

Headquarter 

James 

Borg 

b.  Query  7:  Retrieval  involving  explicit  sett 

Retrieve  the  Social  SecuriQr  Numbers  ci  employees  who  worked  on  project 
numbers  1, 3,  and  10  (or  maybe  mtne). 

(1)  SQL 

SELECT  DISTINCT  ESSN 
FROM  WORKS_ON  Wl  W2  W3 
WHERE  Wl.ESSN  =:W2.ESSN  AND  W1.ESSN  =  W3.ESSN 
ANDWl.PNO=l 
ANDW2.PNO  =  3 
ANDW3.PN0=10 

This  query  is  retrieving  the  distinct  ESSN  attribute  of  an  employee  whose 
PNO  include  all  values  1, 3, 10  or  more.  This  can  be  done  if  the  tuples  satisfy  the  condition 
which  are  specified  in  the  WHERE-clause. 
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(2)  QBE 


WOnCSjQN 

WQ. 

HOURS 

P.UNQ.JC1 

1 

UNQ.JQ 

3 

UNQ.ja 

10 

Conditioa 


JCl  =  jaAND_X2  =  jo 

In  thU  case.  “P.UNQ.JCr.  “UNQ. JC2”.  and  “UNQ. JO”  retrieve 
the  unique  ESSN  of  an  employee  whose  PNO  values  include  all  the  constant  values  1, 3, 
and  10.  All  of  the  tu|4es  retrieved  must  satisfy  the  condition  which  is  speciHed  in  the 
condition  box. 

(3)  DFQL 


(1  3  10) 


This  query  shows  that  a  result  (i2)  of  another  query  make_relation 
which  contains  the  set  values  (1  3  10)  is  an  input  to  the  groupContain^ 
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opai^.TbegroupContain  opoator  takes  the  WCRKS.ON  relatioo  (rl)  and  the  seccMid 
lelatioo  (i2)  and  groiqxi  the  tildes  axoiding  to  the  grcaiping  attribute  essn.  It  then  compares 
attribute  Pno  to  see  if  cxie  essn  has  all  the  Pno  values  cmitained  in  r2.  If  so,  the  essn  is 
selected. 

The  result  of  Query  7  is:  ntme 

e.  Quay  8:  Retrieval  involving  exptteU  uts 

Retrieve  the  social  security  numbers  of  employees  who  worked  on  project 
number  1, 3,  and  10  exactly. 

(1)  SQL 

SELECT  DISTINCT  ESSN 
FROM  WORKS_ON  W1  W2  W3 
WHERE  W1.ESSN  =  W2.ESSN  AND  Wl.ESSN  =  W3.ESSN 
AND  WLPNOal 
AND  WiPNOsS 
ANDW3.PN0=10 
AND  NOT  EXISTS 
(SELECT* 

FROM  WORKS.ON  W4 
WHERE  Wl.  ESSN  s  W4.  ESSN 
AND  W4.  PNO  -  1 
OR  W4.PNOp«3 
OR  W4.PNO^10) 


l.GrotfCoeUiiHoptaexirri^tiaidiGrotip SetComparatioH.GroupSetCompar<aion  alsopro' 
vides  GrmpEqiud  aod  GmfiCoittainBy  opeiatan.  These  opoaton  are  disouMd  in  dan  notes  of 
DeCThomas  Wo,  Computer  Sdcooe  Department,  Naval  PostgradnaieSdiocd.Monteiey.  CA. 
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This  query  is  similar  to  Query  7.  We  can  use  the  NOT  EXISTS 
operator  with  an  included  nested  query  that  checks  the  exj^cit  set  Therefcxe,  a  rephrasing 
would  be  “r^eve  the  social  security  numbers  where  there  are  not  exists  any  employees 
who  woiked  not  on  {xoject  number  1, 3  and  10”.  So,  it  selects  exactly  the  social  security 
numbers  of  employees  who  worked  on  ]»oject  number  1, 3, 10. 

(2)  QBE 


WORKS.Ol  ESSN 

1^1 

HOURS 

P.UNQ.JC1 

1 

UNQ.JC2 

3 

UNQ.JG 

10 

-X4 

_Px 

Condititm _ 

JCl  s  JC2  AND  JC2  *  JO  AND  X3*X4 

In  QBE,  die  query  is  spediied  accmding  to  actual  ccmstant  values  1, 
3  and  10  whidi  satisfy  the  coidition  in  die  condition  box.  This  query  keeps  a  similar 
structure  to  the  Query  7.  “P.UNQ.  JCl”.  “UNQ.  JQ,  “UNQ.  JG”.  and  JC4”  are  used 
to  retrieve  the  tiqiles  which  satisfy  the  ocmdidOT  specified.  Notice  that  the  JC4”  couple 
with  the  condition  ”X3  =  X4”  spedfies  set  equality.  An  essn  is  selected  cmly  if  it  has  PNO 
values  (^1,3,  and  10  and  no  other  values. 


(3)  DFQL 


(I  3  fO) 


This  queiy  also  presents  the  same  structure  as  query  7.  Since  the  query 
is  asking  to  retrieve  the  Social  Security  Numbers  of  employees  who  woriced  on  project 
number  1,  3,  and  10  exactly,  this  query  uses  the  groupEqual  operator  instead  of 
groupContain  operaux'.  It  selects  the  tuples  of  employees  Social  Security  Numbers  only  if 
the  set  of  Rio  values  associated  with  the  essn  is  exactly  equal  to  (1, 3, 10). 

The  result  of  Query  8  is:  none 
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dL  Qunj  9:  Retrieval  involvit^  univenal  quantification 

Retrieve  the  first  name  and  last  name  of  each  employee  who  works  on  all  the 
jxojects  managed  by  department  number  5. 

(1)  SQL 

SELECT  FNAME.LNAME 
FROM  EMPLOYEE 
WHERE  (SELECT  PNO 

FROM  WORKS_ON 
WHERE  SSN  =  ESSN) 

CONTAINS 
(SELECT  PNUMBER 
FROM  PROJECT 
WHERE  DNUMs’S*) 

There  are  two  nested  queries.  If  the  set  of  PNO  values  from  the  first 
nested  query  contains  all  projects  that  are  controlled  by  department  S,  then  the  employee 
tuple  is  selected.  Notice  that  the  CONTAINS  ccnnparison  operator  in  this  query  is  similar 
in  function  to  the  DIVISION  operation  of  the  relational  algebra  [Elma  89]. 


However,  for  SQL  systems  which  do  not  have  the  CONTAINS 
compariscm  operator,  the  user  must  specify  by  using  EXIST  and  NOT  EXIST  functions,  as 
in  the  query  below: 

SELECT  FNAME,LNAME 
FROM  EMPLOYEE 
WHERE  NOT  EXISTS 
(SELECT  * 

FROM  WORKS.ON  B 

WHERE  (B.PNO  IN  (SELECT  PNUMBER 

FROM  PROJECT 
WHERE  DNUM  =  5)) 

AND 

NOT  EXIST  (SELECT  * 

FROM  WORKS.ON  C 
WHERE  C.  ESSN  =  SSN 
AND  C.  PNO  =  B.  PNO)) 

Notice  this  query  involves  two  level-nested  queries.  Thus  this 
fcxmulatitxi  is  quite  a  bit  more  complex  than  the  prior  query  with  the  CONTAINS  q)etat(X'. 
Consider  the  first  nested  query  which  selects  WORKS-ON  (B)  tuples  whose  PNO  is  a 
{xoject  controlled  by  department  5  in  the  IN  q^erator  nested  query,  and  there  does  not  exist 
a  tuple  with  the  same  WfO  and  SSN  in  WORKS-ON  (C)  relation  which  is  related  to  the 
EMPLOYEE  tuple  in  the  outer  query.  Since  the  outer  WHERE-clause  uses  the  NOT 
EXISTS  operator,  negative  logic  is  reflected.  If  the  nested  query  returns  the  empty  tuple, 
the  EMPLOYEE  tuple  should  be  selected.  For  a  detailed  description  see  [EIma89]. 
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1 


(2)  QBE  As  discussed  in  Chapter  II.  QBE  lacks  the  existentiai  and 
universal  quantification  expressions.  Therefore  this  kind  of  query  cannot  be  specified. 

(3)  DFQL 


PROJECT  Dmmi  »  9 


First  we  use  the  select  operate  to  retrieve  PROJECT  tuples  into  rl 
that  match  the  condition  department  number  equals  5,  then  we  project  the  project  numbers 
from  the  result  into  i2.  Concurrently,  we  use  the  join  operator  in  order  to  join  the 
EMPLOYEE  and  WORKS.ON  relations  according  to  equali^  of  the  keys  and  foreign 
keys  esai  and  ssn  into  a  relation,  say  i3.  By  applying  the  groupContain  function  operator, 
it  will  cmnpare  the  tuples  of  the  Pno  attributes  and  splits  the  group  of  tuples  desired  by  ssn. 
Finally,  by  using  the  project  operator,  we  retrieve  the  desired  result  Next  the 
groupContain  function  operator  groups  i3  by  essn.  Then  groupContain  checks  to  see  if  an 
essn  group’s  set  of  Pao  values  contains  all  the  values  in  r2.  If  so,  all  the  tuples  in  the  essn 
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group  are  selected.  The  result  (r4)  flows  to  the  project  function  operator  where  the  desired 
attribute  values  are  obtained  for  display. 

The  output  of  Query  9  is: 


.ENAME 

LNAME 

John 

Smith 

Ramesh 

Naravan 

Joice 

En&lish 

Franklin 

Wona 

e.  Query  1 0:  Retrieval  involving  existential  and  universal  quantification 

List  the  first  name  and  last  name  of  employees  who  worked  exactly  10  hours 
on  each  of  the  projects  they  worked  on. 

(1)  SQL 

SELECT  FNAME,LNAME 
FROM  EMPLOYEE  E 
WHERE  NOT  EXIST 

(SELECT  ESSN 
FROM  WORKS_ON  W 
WHERE  W.  ESSN  =  E  SSN 
AND  EXIST 
(SELECT  » 

FROM  WORKS.ONWl 
WHERE  Wl.  ESSN  =  ESSN 
AND  HOURS <>‘10’)) 

AND 

EXISTS  (SELECT  * 

FROM  WORKS.ON  W2 
WHERE  W2.esn  =  Eessn) 
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This  query  involves  NOT  EXISTS  and  EXISTS  operators  with  two 
nested  queries.  It  selects  the  tuples  of  EMPLOYEE  relation  if  there  does  not  exist  any 
employees  in  the  WORKS_ON  (W)  relation  and  there  exists  an  employee  in  WORKS-ON 
(Wl)  who  does  not  wodc  10  hours  for  all  projects. 

(2)  QBE  As  discussed  in  Chapter  II.  QBE  lacks  the  existential  and 
universal  quantification  expressions.  Therefore  this  kind  of  query  cannot  be  specified. 

(3)  DFQL 


VORKS^H 


Rrst  we  join  the  EMPLOYEE  and  WORKS_ON  relations.  In  DFQL 
we  are  allowed  not  to  declare  specifically  the  condition  according  to  the  key  and  foreign 
key  ssn  and  essn,  as  equi-join,  however,  it  works  similarly,  automatically  matching  the 
tuples  of  both  relations.  Then  applying  the  groupAllSatisJy  operator  takes  care  of  the 
universal  quantification.  Thus,  it  simply  takes  a  relation  rl  and  splits  the  tuples  according 
to  the  grouping  attribute  list,  essn  in  this  case,  and  then  checks  all  the  tuples  in  the 
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individual  group  related  to  the  condition  Hours  =  10.  If  all  the  tuples  satisfy  the  condition 
specified  then  the  values  of  that  grouping  attribute  list  are  passed  out  It  means  that  these 
groups  satisfy  the  condition  by  all  their  tuples.  Finally,  by  using  project  errata',  we 
project  the  desired  tuples. 

The  result  of  Query  10  is: 


FNAME 

LNAME 

Franklin 

Wong 

Alicia 

Zelaya 

f.  Query  II:  Retrieval  involving  Set  Operation 

List  of  all  project  numbers  and  project  names  for  projects  that  involve  an 
employee  whose  last  name  is  ‘Smith*  as  a  worker  or  as  a  manager  of  the  department  that 
controls  the  project 

(I)  SQL 

SELECT  DISTINCT  PNAME,  PNUMBER 
FROM  PROJECT 

WHERE  PNUMBER  IN  (SELECT  PNUMBER 

FROM  PROJECT,  DEPARTMENT,  EMPLOYEE 
WHERE  DNUM  =  DNUMBER 
AND  MGRSSN  =  SSN 
AND  LNAME= ‘Smith’) 

OR 

PNUMBER  IN  (SELECT  PNO 

^  FROM  WORKS  _  ON,  EMPLOYEE 
WHERE  ESSN  =  SSNANDLNAME= ‘Smith’) 
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This  query  uses  IN  operators  and  includes  nested  queries  in  the 
SELECT  query.  The  first  nested  query  selects  the  PNUMBER  of  projects  that  have  a 
‘Smith*  as  a  manager,  while  the  second  selects  the  project  numbers  of  projects  that  have  a 
‘Smith’  as  a  worker.  In  this  query,  the  comparison  operator  ffl  compares  the  value 
PNUMBER  in  the  outer  WHERE-clause  and  evaluates  to  true  if  and  only  if  at  least  one 
value  of  the  sets  result  from  the  nested  queries  matches  it  Fbr  a  detailed  description  of  the 
above  mentioned  and  another  way  to  specify  this  query  using  the  UNION  operator,  see 
[Elma89]. 

(2)  QBE 


EMPLOYEE 

FNAME 

LNAME 

E3 

Smidi 

_Sx 

BDAIE 

ADDRESS 

SEX 

SALARY 

SUPERSSN 

CMO 

DKAME 

MORSSN 

MGRSTAKTDAIE 

J>» 

-Sx 

WORKSjCW 

PND 

HOURS 

-Sx 

-Px 

PROJECT 

FNAME 

PLOCATION 

DNUM 

E 

EJ»X 

JDX 

RESULT 

FNAME 

PNUMBER 

EUNQ. 

-PX 

J*n 

In  QBE,  any  number  of  joins  can  be  specified  in  a  single  query 
[Elma89].  When  we  specify  a  join,  we  can  also  specify  a  result  table  to  display  the  result 
of  the  query,  as  in  the  query  above.  This  is  required  if  the  result  includes  attributes  from 
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two  or  more  relations.  Sometimes,  if  there  is  no  result  taUe  specified,  the  system  provides 
the  query  result  in  the  columns  of  the  varioiK  relation.  This  tends  to  be  difficult  to  interpret 
and  become  meaningless  in  most  cases. 


(3)  DFQL 


Since  the  query  involves  more  than  three  relations,  we  make  use 
several  join  operators.  Hrst  we  select  the  last  name  “Smith”  as  an  employee,  then  the  tuple 
result  flows  to  two  Join  operators.  One  part  joins  with  the  WORKSjON  relation  on  the  left 
side  (we  maiiced  as  “jl”)  and  checks  to  see  if  the  employee  is  a  worker,  and  on  the  right 
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side  (we  marioed  as  “j2”)  joins  with  the  DEPARTMENT  lelaticHi  to  check  the  tuple  to  see 
if  the  employee  is  a  managm'.  Since  we  want  to  obtain  the  tui^es  that  relate  to  Pno  and 
Pname,  we  need  to  join  the  tuples  results  both  sides.  Then  we  use  the  union  operator 
which  takes  all  the  tuples  from  both  sides  and  combines  them  (as  they  are  union 
compatible).  Finally,  employing  the  project  operate,  we  retrieve  the  Pno  and  the  Pname 
that  involve  ‘Smith’  as  a  worker  and  as  a  manager  of  a  department  who  controls  that 
project 

The  result  of  Query  1 1  is:  none 

3.  Statistical  Result 

In  this  category  the  user  (end  user)  attempts  to  obtain  a  i»t^r  relatitm  from  one 
or  more  relations  based  on  a  special  case  of  statistical  rf^ult  This  category  invt^ves 
aggregate  function  operates  such  as  MIN,  MAX.  AVG,  COUNT.  Consider  the  following 
queries: 

a.  Query  12:  Retrieval  inwdving  t^gregate  A  VG  Junction 

Retrieve  the  average  hours  of  woridng  load  for  project  number  3. 

(1)  SQL 

SELECT  AVG  (HOURS) 

FROM  WORKS_ON 

WHERE  PNO  =  ‘3’ 

The  average  function  is  used  to  calculate  the  average  of  the  values  in 
the  HOURS  column  from  the  WORKS  _ON  relation.  The  values  to  be  calculated  must 
satisfy  the  specified  condition  PNO  s  *3*  in  the  WHERE-clause. 
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(2)  QBE 


WORKSjCW 

ESSN 

PNO 

HOURS 

3 

PAVG.  ALL 

In  QBE,  we  place  “3**  as  an  actual  value  which  represent  an  equality 
condititxi  in  the  PNO  cdumn.  And  “P.AVO.”  is  used  to  retrieve  the  average  of  the  values 
that  match  the  conditiraL 

(3)  DFQL 


The  se/ecr  operator  selects  the  tuples  from  the  WORKS_ON  relation 
that  match  the  craidition  specified  “Pno  =  3”.  The  result  is  used  by  next  project  operatOT, 
which  projects  the  average  value  of  the  result  according  to  “AVG  (Hours):  average 
hours..”.  In  this  case,  an  dias  name  is  needed  after  the  colon  to  indicate  clearly  what  the 
result  is  (Tuig93).  The  select  and  project  operatcvs  arc  very  often  used  together.  So,  DFQL 
allows  die  UMr  to  define  a  new  operator  by  giving  a  related  name  selproj  as  a  combine 
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<H)erator.  It  is  used  to  select  the  tajplts  th^  satisfy  the  condition  and  directly  project  the 
desired  attribute  as  a  result 

The  result  of  Query  12  is: 

Average  Hours 
25 


c.  Qutry  13:  Retrieval  involving  AVG  and  Grouping  fiutetion 
Retrieve  the  average  hours  of  working  load  for  each  project 

(1)  SQL 

SELECT  PNO.AVG  (HOURS) 

FROM  WORKS.ON 
GROUP BY  FNO 

Since  we  are  interested  in  the  avoage  hours  d[  each  jxoject  in  SQL  we  have 
to  apirty  the  GROUP  BY-clause.  Here  the  GROUP  BY-clause  is  used  in  wder  to  divide 
WORKS-ON  tuples  into  grcMips  by  tteir  1^0  values.  Then,  the  AVG  functitn  is  used  to 
calculate  the  average  of  the  HOURS  values  of  tuples  according  to  the  PNO  grouping 
attribute  separately. 

(2)  QBE 


WORKSjON 

ESSN 

PNO 

HOURS 

O. 

PAVGALL 

QBE  keeps  the  same  structure  as  (Juery  12  except  in  the  PNO  attribute 
where  we  have  to  place  **G.”  in  cnder  to  group  the  tuples  which  have  the  same  value  in 
FNO.  Then,  AVGALL”  retrieves  the  average  of  the  values  according  to  each  group. 
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(3)  DPQL 


VORKS-OII  Ammrm.. 


DFQL  provides  several  grouping  aggregate  function  operators  for 
statistical  results.  One  of  them  is  the  groupAvg  It  gets  the  tui^es  of  WORKS_ON 

relatitm  and  splits  the  tuples  according  to  groujMng  attribute  PNO,  then  produces  the 
average  of  the  values  of  each  group  of  aggregate  attribute  Hours.  The  result  value  is  given 
an  alias  name  **Avetage  hours’*. 

The  result  of  Query  13  is: 
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d.  Query  14:  Retrieval  involving  County  A  VG  and  Groining  function 


For  each  project  retrieve  the  project  number,  the  number  of  employees  in  the 
project,  and  their  average  hours. 

(1)  SQL 

SELECT  PNO,  COUNT  AVG  (HOURS) 

FROM  WORKS.ON 
GROUP  BY  PNO 

In  this  query,  the  GROUP  BY -clause  is  needed  in  (M'der  to  group 
tuples  by  the  project  number.  Then,  the  AVG  and  COUNT  (*)  operators  calculate  the 
average  hours  and  counted  the  number  of  employees  respectively  for  each  PNO  groupng 
ftVMn  die  WORKS.ON  relation. 

(2)  QBE 


watKS.w 

ESSN 

PNO 

HOURS 

ECNT-ALL 

RG. 

EAVGjUL 

QBE  uses  a  similar  structure  to  Query  13.  Since  Query  13  is 
expanded  by  asking  the  project  number  and  the  number  of  employees  involved  in  each 
I»oject,  it  can  be  specified  by  adding  T.**  beside  **G."  in  the  PNO  attribute  and  placing 
“P.CNT.ALL”  in  the  ESSN  attribute. 
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(3)  DFQL 


This  query  is  an  extension  of  Query  13.  The  ‘TC"  part  is  exactly  the 
same  as  Query  13  and  we  add  the  groupCnt  function  part  “Y”  that  counts  the  number  of 
tujdes  in  each  Pno  group.  Here,  we  need  to  Join  the  tuples  as  a  result  of  part  “X”  and  “Y” 
which  match  according  to  the  Pno.  Finally  the  project  operator  retrieves  the  desired 
attributes  frxmi  tui^es. 


The  result  of  Query  14  is: 


Pno 

The  number  of  employees 

Average  Hours 

1 

2 

26l2S 

2 

3 

ia75 

3 

2 

25.00 

10 

3 

27.50 

20 

3 

1250 

30 

3 

27.50 

S7 


d.  Query  IS:  Retrieval  involving  Count  and  A  VG  function 

Retrieve  the  number  of  emf^oyees  and  their  average  hours  who  worked  on 

projects. 

(1)  SQL 

SELECT  PNO.  COUNT  (*).AVG  (HOURS) 

FROM  WORKS.ON 
WHERE  PNOs=‘3* 

This  query  is  an  extension  of  Query  12  in  which  we  can  count  the 
number  of  employees  by  applying  die  function  COUNT  (*).  Since  we  are  concerned  with 
a  particularly  project,  it  is  specified  as  a  condition  in  the  WHERE-clause. 

(2)  QBE 


WOUCSJDN 


P.CNr.ALL 


PNO  HCXJRS 


RAVG.AL 


The  only  different  with  Query  12  is  the  “P.CNT.ALL”.  It  retrieves  the 
number  cS  employees  that  match  the  condition  specified  under  the  PNO  column. 


(3)  DFQL 


In  this  query,  the  “X”  part  is  the  same  as  Query  12,  and  we  add  the 
groupCnt  (q)erat(n’  “Y”  part  in  order  to  count  the  number  of  employees  who  participate  in 
project  number  3.  Next  we  need  to  join  the  tuples  as  a  result  of  both  sides  “X"  and  “Y”. 
Thmi,  the  project  operator  is  used  to  retrieve  the  desired  attribute  values. 


The  result  of  Query  15  is: 


Average  Hours 

The  number  of  employees 

25 

2 

«9 


€.  Quay  1 6:  Rttrieval  involving  Max  and  Grouping  function 


For  each  department  retrieve  the  employee’s  social  security  number  who  1^ 
the  highest  salary. 

(1)  SQL 

SELECT  DNO.SSN.MAX  (SALARY) 

FROM  EMPLOYEE 
GROUP BY  DNO 

The  employment  of  the  MAX  aggregate  function  is  used  in  order  to 
obtain  the  maximum  (or  highest)  value  of  the  SALARY  attribute  from  the  EMPLOYEE 
relation.  We  select  the  tuples  with  the  max  salary  from  each  group  according  to  DNO  in  the 
GROUP  BY-clause.  Based  on  DNO  and  highest  pay  we  also  retrieve  from  the  tuple  the 
SSNs  attribute  value. 

(2)  QBE 


EMPLOYEE 

FNAME 

SSN 

BOATS 

ADDRESS 

SEX 

SALARY 

DNO 

P. 

PMAXJtLL 

G. 

In  QBE  we  just  need  to  specify  “G.”  in  the  DNO  attribute  in  order  to 
separate  into  each  group.  The  “P.MAX.  ALL”  is  specified  to  get  the  tuple  with  highest 
salary  in  the  SALARY  attribute  from  all  tuples  in  each  group  of  DNO.  And  the  other  “P.” 
is  used  to  retrieve  the  SSNs. 


70 


(3)  DFQL 


The  structure  which  is  specified  for  this  query  is  similar  to  the 
previous  queries  that  involve  the  groupAvg  operator.  The  only  different  is  we  have  lo  use 
the  groupMax  operator.  The  result  of  groupMax  is  the  tuple  of  each  Dno  group  with  the 
highest  pay.  Since  we  are  also  interested  in  the  ssn  of  selected  employees,  we  join  the 
EMPLOYEE  relation  to  the  result  mentioned  above.  Then,  by  using  the  project  curator 
we  retrieve  the  attributes  desired. 


The  result  of  Query  16  is: 


Dno 

.SSN 

Max  pay 

5 

333445555 

40000 

4 

987654321 

43000 

1 

888665555 

55000 
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/  Qmry  1 7:  Retrieval  involving  Max  and  Grouping  function 

For  each  department  retrieve  employee  (SSNs)  and  their  dependent  name, 
who  has  the  highest  pay. 

(1)  SQL 

SELECT  DNO,  SSN.  DEPENDENT_NAME,  MAX  (SALARY) 
FROM  EMPLOYEE  E,  DEPENDENT  D 
WHERE  ESSN  =  D.  ESSN 
GROUP  BY  DNO 

The  above  query  is  extended  from  Query  15  in  which  the 
DEPENDENT  relation  is  involved.  In  this  query  we  select  the  tuples  from  EMPLOYEE 
and  DEPENDENT  relation  according  to  the  attributes  list  in  SELECT-  clause  which  satisfy 
the  join  condition  specified  according  to  the  keys  SSN  and  ESSN  in  E  SSN  =:  D.  ESSN. 
The  DNO  which  is  specified  in  GROUP  BY-clause  is  used  to  separate  the  tuples  of  DNO 
in  each  group. 

(2)  QBE 


JSx  P. 


Here  we  need  to  join  the  two  relations  EMPLOYEE  and 
DEPENDENT  by  using  the  “_Sx”  as  an  example  variable  that  we  place  in  the  key  attribute 
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of  SSN  and  ESSN.  The  “G.”  is  used  to  separate  the  tuples  in  each  group  according  to  the 
DNO,  Then,  “P.MAX.  ALL”,  “P.",  and  “P._Sx”  are  used  to  retrieve  the  values  of  the 
attributes  desired. 

(3)  DFQL 


Since  Query  17  is  an  extension  of  Query  16,  we  see  relation  ri  is  a 
result  of  Query  16  which  holds  the  tuples  of  [dno,  ssn,  max  pay..].  Then  we  need  a  join 
qjerator  for  the  purpose  of  joining  with  the  DEPENDENT  relation  T2  according  to  the  keys 
ssn  and  essn  of  both  relations.  The  tuples  as  a  result  of  the  cartesian  product  that  we 
obtained  from  the  Join  operator  above  are  used  by  the  project  operator  in  order  to  retrieve 
the  values  of  ssn(s)  and  the  Dependent^jiame. 
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The  result  of  Query  17  is: 


SSN 

Dependent-name 

333445SS5 

Alice 

987654321 

Abnar 

88866SS55 

- 

g.  Query  18:  Retrieval  involving  AVG^  Max^  Suntf  and  Grouping  Junction 
Retrieve  the  average,  maximum  and  sum  of  the  salaries  of  each  department’s 
highest  paid  employee. 

(1)  SQL 

SELECT  AVG  (SALARY).  MAX  (SALARY),  SUM  (SALARY) 
FROM  EMPLOYEE  E 

WHERE  ESALARY  IN  (SELECT  DNO,  MAX  (SALARY) 

PROM  EMPLOYEE  El 


GROUP  BY  DNO) 

Again  if  we  increase  the  complexity  of  Query  16  to  Query  18  as 
above,  SQL  presents  a  structure  which  is  quite  different  from  the  query  16.  Here  the 
GROUP  BY  concerns  DNO  in  the  nested  queries  in  order  to  separate  the  tuples  and 
calculate  the  highest  paid  employees.  Then,  the  outer  query  specifically  calculates  the 
AVO,  MAX,  and  SUM  values  of  the  highest  paid  of  all  groups  in  the  department 
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(2)  QBE 


EMIOYS 


R4AME 


KUNTT 


LNAMB 


BOATE 


ADDRESS 


SEX 


SALARY 


SUFERSEN 


ONO 


PJMAXJVLL 


G. 


Result 

Dept  top  pay 

P. 

MAXALLAVGALL.SUMALL 

In  QBE,  this  type  of  qittry  can  be  specified  into  two  steps,  where  first 
we  attempt  to  retrieve  the  highest  paid  according  to  each  group  of  the  DNO.  Then  we 
retrieve  the  attribute  values  of  selected  tuples  by  placing  the  ’’P.’*  under  the  Result  column 
and  “MAX.ALL.AVG.ALL.SUM.ALJL”  under  the  Dept  top  pay  column. 

(3)  DFQL 
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[ 

t 

^  Again,  in  this  query  Um  results  of  Query  16  can  be  used  as  a  source  or 

\ 

as  an  input  to  the  other  group  operators.  In  the  case  of  this  query  groupStat^  operators  are 
used  to  perform  the  calculation  of  avg  (max  salary),  sum  (max  salary),  and  max  (max 
salary).  Here,  each  of  these  operators  produces  the  values  we  are  concerned  with. 


The  result  of  Query  18  is: 


Avg  (max  pay) 

Sum  (max  pay) 

Max  (max  pay) 

46000 

138000 

55000 

h.  Query  19:  Retrieval  involving  Count  and  Grouping  fiinction 

For  each  department  retrieve  the  department  name  and  the  total  number  of 
employees  who  are  paid  more  than  $40,0(X). 

(1)  SQL 

SELECT  DNO.DNAME,  COUNT  (*) 

FROM  EMPLOYEE,  DEPARTMENT 

WHERE  DNUMBER  s  DNO  AND  SALARY  >  40000 

GROUP BY  DNO 

Like  the  previous  queries,  the  GROUP  BY  -clause  is  used  to  separate 
the  tuples  into  groups  by  DNO  attribute  value.  Then,  the  values  of  the  attributes  listed  in 
SELECT-clause  are  selected  from  EMI^OYEE  and  DEPARTMENT  relation  in  the 
FROM-clause  which  satisfy  the  conditions  spedfied  in  the  WHERE-clause. 


1.  QioB|»tat  opmior  if  discosaed  in  notes  of  Dr.  C  Thomn  Wu,  Computer  SdeQoe  Dqiutoient, 

Nml  IViitgniAiate  School,  Mcmterey. 
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(2)  QBE 


DNAME 

MORSSN 

MQRSTARTDAIE 

R 

JDk 

1 125531 

FNAME 

2^22 

INAME 

IS 

SEX 

SAUunr 

SWQtSEN 

DNO 

>40000 

RO.CNTAULJDx 

In  this  query  the  “P.G.CNT.ALL.  JDx”  is  specified  in  order  to  retrieve 
the  tuples  based  on  the  grouping  “Q.**  of  DNO  attribute,  and  CNT.  ALL  is  used  to 
count  DNO  in  each  group  to  reinosent  the  number  of  employees.  All  of  these  can  be 
performed  if  the  tuples  match  '  join  condition  specified  by  **_Dx'*  according  to  the  key 
and  fcxoign  key  DNUMBER  and  DNO. 


77 


(3)  DFQL 


Hrst  we  select  the  tuples  of  the  EMPLX>YEE  relation  that  fulfill  the 
condition  Salary  >  40000.  Then  we  join  the  result  of  the  select  operator  with  the 
DEPARTMENT  relation  by  equality  of  the  key  and  foreign  key  Dnumber  and  Dno.  Then, 
the  result  is  used  by  the  groupCnt  operator  which  splits  the  tuples  aoc(»xlmg  to  Dno  groiqjs. 
Finally,  by  using  the  project  opemor,  we  retrieve  the  values  of  the  dname  and  dno,  and  also 
the  numbo*  of  employees. 


The  result  of  Query  19  is: 


Dname 

Dno 

The  number  of  Employees 

Administtation 

4 

1 

Headquarter 

1 

1 

4.  Sct-€>Nint  Value 


In  diis  cat^ocy  the  usor  (eiKl  user)  is  interested  in  obtaining  a  propa*  relation  frcxn 
one  or  more  relations  based  mi  a  special  case  set-count  testing.  Consider  the  fcdlowing 
queries: 

a.  Qiury  20:  RetrUnU  invoMng  txUtentkd  quantification 

Retrieve  the  first  name  and  dre  last  name  of  managers  who  have  at  least  one 
female  as  a  dependent 

(1)  SQL 

SELECT  FNAME.LNAME 
FROM  EMPLOYEE 
WHERE  EXISTS(SELECT  * 

FROM  DEPENDENT 
WHERE  SSNsESSN 
AND  SEX=‘F) 

AND  EXISTS  (SELECT  * 

FROM  DEPARTMENT 
WHERE  SSN=MORSSN) 

One  way  to  specify  this  query  as  shown  above  involves  two  nested 
qumies.  The  first  nested  query  selects  all  DEPENDENT  tuples,  and  the  seccmd  selects  the 
DEPARTMENT  tuples  managed  by  the  EMPLOYEE  Therefore,  if  there  exists  at  least  one 
tiqile  dqpendmit  with  SEX  equal  to  female  in  the  first  nested  query,  and  at  least  tme  tufrfe 
of  the  csnidoyee  who  managed  the  department;  then  the  EMPLOYEE  tuple  is  selected 
aococding  to  the  FNAME  and  LNAME  of  the  emfdoyees. 
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(2)  QBE  As  discussed  in  Chapter  II,  QBE  lacks  the  existential  and 
universal  quantification  exfvession.  Therefore  this  kind  of  query  cannot  be  specified. 

(3)  DFQL 


DEPARTMENT 


Hrst  we  join  the  EMnjOYEE  and  DEPARTMENT  relation  by  using 
the  equi-j<w  based  on  their  key  and  foreign  key.  in  this  case  ssn  =  mgrssa  Then,  the  tuples 
as  a  resulted  the  eqm-jmn^  say  as  rl  Hows  to  the  next  join  operator.  At  this  pennt  rl  contains 
the  tuples  of  employees  who  manage  a  department  joined  with  DEPENDENT  relation,  say 
i2,  according  to  the  key  and  foreign  key  j<m  condition  rl.ssn  s  t2.  essn.  Then,  by  applying 
setproj  oporator,  we  select  the  tuples  desired  which  satisfy  the  condition  qjecified  “Sex  = 
F*  and  direedy  pngect  or  retrieve  the  values  c^Fname  and  Lname  of  the  ntanager. 

The  result  (rf*  Query  ^  is: 


b.  Qumj  21:  R/gtrUnd  invobring  Count  and  Grouping  fitnetion 

Retrieve  tfae  total  number  of  employees  widi  salaries  more  than  $40,000  who 
worked  in  each  department,  but  only  for  those  departments  where  more  than  four 
employees  wok. 

(1)  SQL 

SELECT  DNAME,  COUNT  (*) 

FROM  DEPARTMENT,  EMPLOYEE 
WHERE  DNUMBER  *  DNO  AND  SALARY  >  40000 
AND  DNO  IN  (SELECT  DNO 

FROM  EMPLOYEE 
GROUP  BY  DNO 
HAVING  COUNT  (*)>4) 

GROUP  BY  DNAME 

While  reading  Query  21,  it  can  lead  to  misunderstanding  the  point  in 
specifying  the  SQL  query.  It  may  lead  us  to  specify  the  query  as  fc^ows: 

FROM  DEPARTMENT,  EMPLOYEE 
WHERE  DNUMBER  =  DNO  AND  SALARY  >  40000 
GROUP BY  DNAME 
HAVING  COUNT  (*)>4 

This  is  an  incorrect  query  since  it  will  retrieve  only  departments  that 
have  more  than  five  employees  who  each  earn  more  them  $40,000.  For  a  more  detailed 
(Ascription  of  die  above  queries  see  [EIma89]. 

Query  21  is  expanded  frmn  Query  19  in  the  previous  Section  *3.  h.”, 
but  they  are  very  different  in  structure.  Query  21  is  specified  by  using  the  nested  query. 
While  specifying  this  land  of  query  we  must  be  careful,  espedally  when  we  have  to  apply 
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two  differrat  conditicMis  like  the  query  above;  where  *^ALARY  >  40000”  is  sq^lied  to  the 
COUNT  function  in  the  SELECT-cIause  and  the  other  in  the  HA  VING-clause.  And  for  the 
GROUP-BY  function,  Bmasri  comments  “Some  SQL  implementations  may  not  allow  a 
GROUP  BY-clause  without  a  function  in  the  SELECT-clause.  Hence,  the  nested  query  in 
this  example  (Query  21(1)  SQL)  cannot  be  permitted  in  such  SQL  implementations”. 

(2)  QBE 


DEPARTMEhfT 

DMAME 

MGRSSN 

MGRSTARIDATE 

P. 

EMPLOYEE 

1^2211 

LNAME 

m 

BDAIE 

SEX 

SALARY 

B 

DMO 

>40000 

P.G.CNrALL.JDx 

Cdndidtm 

I  c>rr.ALL.j^>4 


Here,  QBE  really  keeps  a  structure  similar  to  (^ery  19.  Here  we  need 
to  specify  in  the  condition  box  “CNT.AU-.  JDx  >  4”  in  order  to  retrieve  the  total  number 
of  employees  if  it  is  more  than  four  members  in  each  department  according  to  the  value  of 
DNO. 
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Since  it  is  expanded  from  Query  19,  we  can  use  all  Query  19  and 
connect  it  with  the  new  part  of  the  query.  The  “X”  is  the  whole  part  of  Query  19  and  “Y” 
is  related  to  groupCnt  and  select  c^rerattxs,  which  spedflcally  count  the  tujdes  aconding 
to  Dno  in  <xder  to  represent  die  total  number  of  employees  as  a  specified  ccmditioiL 
The  result  of  Query  21  is:  ntme 
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e.  Query  22:  Retrieval  involving  Count  and  Grouping  Junction 

For  each  project  on  which  there  are  three  or  more  employees  working, 
retrieve  the  project  number,  project  name,  and  number  of  employees  who  work  on  that 
project 

(1)  SQL 

SELECT  PNUMBER,  PNAME,  COUNT  (*) 

FROM  PROJECT,  WORKS_ON 
WHERE  PNUMBER  =  PNO 
GROUP  BY  PNUMBER.  PNAME 
HAVING  COUNT  (»)>3 

This  query  involves  two  relations  PROJECT  and  WORKS-ON.  Here, 
the  GROUP  BY-clause  is  used  in  order  to  separate  the  project  in  each  group  and  selection 
of  tuples  is  used  to  satisfy  the  join  condition  in  WHERE-clause.  The  HAVING-cIause  in 
this  case  uses  whcde  groups  of  {xojects,  and  specifically  specifies  the  number  (rf  employees 
which  satisfies  the  groups  themselves. 


Condition 

CNr.ALL._P)i»3 


Here,  P.G.CNT.ALL._Px’’  is  specified  in  order  to  retrieve  the  tuples 
of  the  grouping  attribute  of  1^0  which  satisfied  the  join  condition  related  to  the  key  of 
PNUMBER  and  PNO.  But,  it  must  satisfy  the  condition  box  “CNT.  ALL._Px  >  3”.  Here 
the  use  of  the  condition  box  is  similar  to  the  HAVING-clause  in  SQL. 


(3)  DFQL 


Wc  join  the  two  relations  PROJECT  and  WORKS-ON  according  to 
the  join  condition  Pttumber  =  Pno.  The  tuples  of  the  cartesian  product  is  flowed  to 
groupCnt  operaUH*,  and  it  sfdits  Pno  into  each  group.  Then,  it  selects  the  tuples  that  fulfil 
the  condition  specified  “cnt  %  3  **38  counting  the  number  of  em|rioyees.  Through  the  project 
(^rator  we  retrieve  the  tuples  needed  according  to  the  attribute  list 
The  result  of  Query  22  is: 


Poame 

Pnumber 

The  number  of  employees 

ftoductY 

2 

3 

Computeiizaticm 

10 

3 

Reorganization 

20 

3 

Newbenefit 

30 

3 
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d.  Query  23:  Retrieval  involving  Count  function 


Retrieve  project  name,  where  there  are  three  or  more  employees. 

(1)  SQL 

SELECT  PNAME 

FROM  PROJECT 

WHERE  (SELECT  COUNT  (*) 

FROM  WORKS_ON 
WHERE  PNUMBER  =  PNO)  i  3 
By  modifying  Queiy  22  just  a  little  bit,  we  get  Query  23.  One  way  to 
specify  the  SQL  query  is  shown  above  involving  a  nested  query.  The  nested  query  counts 
the  tuples  (representing  the  number  of  employees)  involved  in  the  project  in  the 
WORKS_ON  relation.  If  it  is  greater  than  or  equal  to  three,  the  PROJECT  tuple  is  then 
selected.  In  some  imfdementations  of  SQL  the  above  query  may  not  be  permitted  [Elma89]. 

(2)  QBE 


PROJECT 

PNAME 

PLOCATIW 

DNUM 

R 

WORKSJON 

ESSN 

PNO 

HOURS 

CNTALLJ^  »3 

In  this  query  “CNT.  ALL._PX  2  3”  counts  the  tuples  concerning  the 
number  of  employees.  If  it  is  greater  than  or  equal  to  three  then  the  tuples  of  Pname  are 
retrieved  by  “P.”  according  to  key  as  specified  by  an  example  value  “_Px”. 


(3)  DFQL 


In  order  to  get  the  counting  result,  DFQL  in  this  case  applies  the 
groupCra  operator  in  all  kind  dL  queries  that  relate  to  set  count  query.  That’s  why  Query  22 
and  Query  23  are  specified  with  exactly  the  same  structure,  just  slightly  different  in  the 
attribute  list  of  the  tuples  desired. 

The  result  of  Query  23  is: 


Pname 

The  number  of  employees 

RoductY 

3 

Computerization 

3 

Reorganization 

3 

Newbenefit 

3 

By  loddng  at  the  results  of  Query  22  and  23,  we  notice  that  the  tujdes 
results  of  PNAME  and  the  total  number  of  employees  retrieved  are  absolutely  equal.  In 
slK»rt,  we  can  say  that  both  Query  22  and  23  are  really  the  same  in  the  structure. 


e.  Query  24:  Retrieval  involving  univenalquantifiaUion 

Retrieve  project  name,  where  there  are  three  or  more  employees,  and  all  of 
them  has  a  work  load  of  20  hours. 

(1)  SQL 

SELECT  PNAME 

FROM  PROJECT  P,  WORKS_ON  W 

WHERE  P.PNUMBER=W.PNO 

AND  PNO  IN  (SELECT  PNO 

FROM  WORKS.ON 
WHERE  HOURS  =  20 
GROUP  BY  PNO 
HAVING  COUNT  (*)  *3) 

Query  24  above  is  an  extension  of  Query  23.  In  the  SQL  query  above, 
the  GROUP  BY>clause  and  HAVING-clause  are  particularly  related  to  PNO  in  the  nested 
query.  If  each  group  of  PNO  tuples  satisfies  the  condition  “HOURS  =  20”,  and  also  if  in 
each  PNO  there  are  three  or  more  emplr^ees  as  a  worker,  then  the  PROJECT  tuple  will  be 
selected.  However,  it  must  satisfy  the  join  condition  specified  in  the  WHERE-clause. 

(2)  QBE  As  discussed  in  Chapter  II,  QBE  lacks  the  existential  and 
universal  quantification  expressions.  Therefore  this  kind  of  query  canix)t  be  specified. 
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(3)  DFQL 


Consider  the  DFQL  query  above.  Part  is  Query  23,  and  it  can  be 
directly  used  as  a  relation  to  be  an  input  to  the  groupAUSatisfy  operator.  It  takes  the  tuples 
and  splits  the  tuples  according  to  the  PNO  as  a  grouping  attribute,  and  the  tuples  in  each 
group  must  satisfy  the  condition  specified  ‘‘Hours  =20”.  Then,  we  retrieve  the  tuple  result 
of  the  attribute  desired  by  using  die  project  operator. 

The  result  of  Query  24  is:  none 
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f.  Quuy  25:  Retrieval  involving  univertal  quantification 

Retrieve  the  department  names  which  offer  two  or  more  projects  where  there 
are  three  or  more  emf^oyees  who  worked  on  it,  and  all  of  them  has  a  work  load  of  20  hours. 

(1)  SQL 

SELECT  DNAME 

FROM  DEPARTMENT  D,  WORKS.ON  W,  PROJECT  P 

WHERE  D.DNUMBER  =  P.DNUM 
AND  P.PNUMBER=W.PNO 
AND  PNO  IN  (SELECT  PNO 

FROM  WORKS-ON 
WHERE  HOURS  =  20 
GROUP  BY  PNO 
HAVING  COUNT  (*)  fc3) 

GROUP  BY  DNUM 
HAVING  COUNT  (*)a2 

(2ueiy  25  is  expanded  from  Query  24,  and  the  complexity  of  the  query 
has  increased.  This  query  involves  three  relations  and  nested  query.  A  GROUP  BY  -clause 
and  HAVING-clause  are  used  specifically  for  the  nested  query,  and  another  GROUP  BY  - 
clause  and  HAVING-clause  are  used  fcM-  the  whole  groups.  Even  though  this  query  is  just 
slightly  different  from  previous  Query  24,  we  have  to  rewrite  while  specifying  this  query. 


(2)  QBE.  As  discussed  in  Chapter  II,  QBE  lacks  the  existential  and 
universal  quantificaticMi  expressions.  Therefore  this  kind  of  query  cannot  be  specified. 

(3)  DFQL 


Notice  that  the  "X”  part  is  Query  24.  The  tujrfe  result  is  directly  used 
as  a  relation  to  be  joined  with  the  DEPARTMENT  relation  according  to  the  key  and  fcxagn 
k^  Dnumbn’  and  Dnum.  The  result  of  the  cartesian  product  which  is  produced  by  they^^m 
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(^gerettM'  flows  to  the  groupCnt  operator  which  groups  according  to  the  grouping  attribute 
of  Dnum.  Then,  by  emi^oying  the  selproj  qjerator  we  can  count  specifically  the  tuples 
which  satisfy  the  condition  specified,  and  directly  project  the  values  desired  of  the  attribute 
list 

The  result  of  Query  25  is:  none 

B.  ANALYSIS 

In  the  previous  section,  we  observed  how  SQL,  QBE,  and  DFQL  specify  all  of  the 
query  examples  which  are  composed  in  categories.  Queries  range  from  simple  ones  to 
queries  which  involve  existential  or  universal  quantifications,  and  complex  nested  queries 
in  SQL.  Some  of  the  queries  are  stand-alone,  but  some  others  specified  are  logical 
extensions  in  complexity  from  one  query  to  the  next  By  examining  these  queries  the 
relative  strengths  and  weaknesses  related  to  ease-of-use,  especially  in  expressing  universal 
quantification,  specifying  the  complex  nested  queries,  and  flexibility  and  consistency  in 
fcxmulating  the  queries  with  respect  to  data  retrieval  for  RDBMS’s  are  investigated. 

1.  Eaae^if-use 

Ease-of-use  of  query  languages  is  part  of  the  human  factor  aspect  In  this  research 
we  emphasize  the  learning  and  writing  of  the  query,  as  well  as  attempting  to  retrieve  the 
output  result  However,  we  have  to  keep  in  mind  that  query  languages  are  high  level 
langua^  that  are  also  intenctod  to  be  used  by  non  programmers.  Related  to  Ease-c^-use, 
srmie  researchers  described  that* 

•  The  SQL  language  has  been  designed  and  intended  to  be  easily  learned  and  used  by 
inexperienced  user  without  specialized  computer  training  [Reis75]. 

•  The  result  of  various  psychdogical  studies  trf  language  (QBE)  show  that  it  requires 
less  than  three  hours  of  instruction  for  non  {nogrammers  to  acquire  the  skill  to  make 
fairly  comfdicated  queries  (TlooTT].  Peo|4e  will  write  queries  in  QBE  between  two  or 
three  times  faster  than  in  SQL  [ReisSl]. 
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•  DFQL  is  ixoposed  and  implemented  to  mitigate  problems  that  are  encountered  by  the 
current  query  languages,  SQL  in  particular.  It  requires  about  half  an  hour  in  a  database 
class  at  NPS  to  acquire  the  concept  and  make  more  correct  queries  than  SQL  [Clat91]. 

Accofxling  to  our  research  through  the  previous  Section  “A.”  of  this  chapter,  the 
above  ctxnments  and  results  are  absolutely  valid  for  QBE  and  DFQL  but  not  for  SQL. 
Cmisider  the  representative  sets  of  queries  tiiat  we  have  in  each  category  or  from  one 
category  to  the  other  categories.  Here  ease-of-use  of  each  language  can  be  pointed  out 
clearly,  where  “once  we  learn  a  general  construct  from  a  sample  query,  if  the  way  of 
thinking  can  be  applied  in  a  new  query”  we  can  say  that  there  is  certain  degree  of  ease-of- 
use.  For  example,  when  we  learn  the  technique  to  drive  a  car  for  500  yards,  then  we  could 
most  likely  can  drive  for  another  1000  yards.  Now,  let’ s  take  a  look  at  some  of  the  queries 
that  we  have. 

a.  Queriei  involving  exiitential  or  universal  quant^ication 

In  the  fdlowing  discussicMis  we  covers  several  queries  that  are  composed  in 
single-value,  set-value,  and  set-count  value  categories.  Consider  the  queries  below: 

•  Query  4:  Retrieve  the  department  numbor  where  all  of  its  employees  have  salaries  of 
more  than  $40,000. 

•  Query  5:  For  each  department  retrieve  the  first  name  and  the  last  name  of  employees 
who  have  no  d^ndents. 

•  Query  6:  Retrieve  the  first  name,  last  name  and  department  names  where  all  of  its 
employees  have  salaries  trf*  mtxe  than  $40,000  and  have  no  dependents. 

By  looking  at  these  three  queries  we  realize  that  Query  6  is  virtually  the 
oomlxnation  of  Query  4  and  5.  Now  let’s  consider  how  do  SQL,  QBE,  and  DFQL  construct 
all  of  these  queries. 

(1)  SQL.  See  die  construct  of  die  structure  of  Query  4  and  Query  5,  whoe 
both  queries  contain  NOT  EXISTS  operators  that  interpret  the  queries  in  a  negative  logic 
af^iroadi.  Genmally,  these  kind  of  query  structures  are  not  easy  to  understand,  especially 
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Query  4.  Assume,  we  understand  the  construct  of  both  queries,  however  we  cannot  apply 
this  similar  thinking  to  specify  the  structure  of  Query  6.  In  this  case,  we  do  have  to  think 
very  carefully  since  we  have  to  specify  a  new  query  that  may  be  very  different  in  the 
structure.  Therefore,  these  types  of  queries  are  difficult  to  specify  even  for  the  experienced 
users. 

(2)  QBE  QBE  lacks  universal  quantification  expressions.  Therefore  we 
cannot  express  these  types  of  queries. 

(3)  DFQL.  By  learning  the  construct  of  Query  4  and  Query  5,  we  can  use 
the  similar  thinking  of  Query  4  and  Query  5  in  order  to  form  a  new  Query  6.  Once  we  know 
the  construct  of  Query  4  and  Query  5  we  can  use  them  in  the  other  new  query  easily.  Notice 
in  Query  6  that  the  “X”  part  retrieves  the  tuples  of  employees  who  have  salaries  of  more 
than  $40,000,  as  Query  4,  and  that  the  “Y"  port  retrieves  employees  who  do  not  have 
dependents.  We  can  logically  combine  these  two  constructs  by  using  the  intersect  operator 
that  combines  union  compatible  tuples  so  that  we  have  the  tuples  of  all  employees  who 
have  salaries  more  than  $40,000  and  have  no  dependents.  Since  we  ate  interested  in  the 
departmoit  name  also,  we  can  easily  join  the  tuples  result  above  as  new  relation  (r3)  with 
the  DEPARTMENT  relation  (r4)  which  match  according  to  the  key  and  feweign  key  of  both 
rdatKHts,  r3.  Dno  =  r4.  Dnumber.  Finally,  by  employing  the  project  operator  we  retrieve 
from  the  tiqries  the  first  name,  last  name,  and  department  names  of  those  employees. 

By  investigating  the  above  queries,  once  we  learn  how  to  specify 
Query  4  and  Query  5,  we  can  generalize  them  in  a  straight  forward  manner  to  spedfy  Query 
6.  We  can  say  that  this  language  is  easy  to  learn  (and  thus  easy  to  use).  Consider  the 
following  queries  that  are  similar  to  the  above  discussions: 

•  See  Query  9, 10,  which  are  difficult  to  specify  in  SQL,  caimot  be  specified  in  QBE 
(see  QBE  desmption  in  Chapter  1I.C.1.C.),  but  are  very  easy  in  DFQL  since  we  can 
apiriy  the  construct  ccmcept  of  Query  4. 

•  Qt*«y  20  also  8ho\i«  that  in  SQL  it  is  not  easy  to  learn  or  understand  the  structure,  and 
in  QBE  it  cannot  be  expressed.  (See  QBE  description  in  Chapter  II.C.1.C.).  But  in 
DFQL  the  data  flows  from  one  part  to  another  are  easy  to  follow  and  one  can 
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unctersiancl  what’s  gdng  on. 

b.  Queries  involving  nested  queries 

In  this  section,  we  analyze  queries  which  involve  the  IN  operator  in  the  nested 
query.  In  addition,  we  also  examine  several  queries  which  contain  the  universal  quantifier 
in  the  nested  queries.  Ctnisider  the  following  queries  in  the  set-count  value  category: 

•  Query  21:  Retrieve  the  total  number  of  employees  with  salaries  more  than  $40,000 
who  w<»1ced  in  each  department,  but  cmly  for  those  departments  where  moe  than  four 
employees  work. 

However,  before  going  into  any  detail  in  Query  21,  see  first  Query  19  in  the 
set-value  category.  By  examining  these  two  queries  we  realize  that  Query  19  is  expanded 
to  Query  21. 

•  Query  19:  For  each  department  retrieve  the  department  name  and  the  total  number  of 
employees  who  are  paid  mote  than  $40,000. 

Similar  to  the  above  description  **l.a.’*  we  attempt  to  leam  the  construct  from 
<Hie  sample  query  and  extend  it  to  create  another  new  query.  Ccsisider  how  SQL,  QBE  and 
DFQL  construct  both  queries: 

(1)  SQL.  When  we  leam  Query  19  and  understand  the  constract,  we  are 
still  not  ccmfident  of  how  to  specify  the  structure  for  Query  21  (or  an  incorrect  query  can 
be  specified,  see  SQL  query  below  Query  21).  In  other  words,  in  SQL  we  cannot  use  the 
construct  of  a  sample  query  to  build  a  new  query  in  a  straight  forward  manner. 

(2)  QBE.  In  QBE  we  realize  that  the  same  thinking  of  the  constract  in 
(2uery  19  can  also  be  used  to  specify  (^ry  21.  QBE  in  this  case  i»esents  a  simile  and  very 
intuitive  exten^on. 

(3)  DRJL.  When  we  leara  the  construct  of  Query  19,  it  is  easy  to 
understand  Query  21.  Here,  the  constract  of  Query  19  can  be  used  as  a  part  of  Query  21. 
To  build  Query  21  we  know  that  we  need  two  parts;  first  the  employees  with  salaries  more 
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than  $40,000  and  second,  tuples  of  those  department  with  more  than  four  employees.  See 
Query  21  o[  DFQL  for  details. 

We  also  look  at  several  queries  which  are  similar  to  the  above 
discussion.  These  types  of  queries  are  composed  in  the  set-value,  statistical-result,  and  set- 
count  categories.  Consider  the  queries  below: 

•  Query  7  is  extended  to  Query  8. 

•  Query  16  is  extended  to  Query  18. 

•  Query  22  is  modified  to  Query  23. 

•  Query  23  is  extended  to  Query  23. 

•  Query  24  is  extended  to  Query  25. 

In  addition  to  discussion  in  “l.a”  and  “l.b”  above,  see  Query  1  in  the  single¬ 
value  category.  If  we  are  interested  in  the  value,  in  SQL  we  have  to  use  the  keyword 
“DISTINCT*  in  the  SELECT-clause,  and  in  QBE  the  prefix  “UNQ.”.  On  the  contrary, 
DFQL  implements  the  primitive  operators  which  have  a  similar  capabilities  to  the 
relational  algebra  operators,  so  the  duplicate  tuples  in  the  query  result  are  eliminated  In  this 
case,  we  consider  that  DFQL  is  easy  to  use,  sirrce  we  do  not  need  to  worry  when  and  where 
we  have  to  eliminate  the  duplicate  tuples.  For  detailed  problems  concerning  the  duplicate 
tu{des  see  [Codd90]. 

Next  we  examine  the  query  that  involves  select-project-join  with  two-join 
condrtirms.  See  Query  3.  In  SQL  it  is  not  easy  to  comprehend  what  is  going  on  in  the  query. 
QBE  in  this  case  presents  a  simple  construct  in  which  it  is  easy  to  follow  the  joining 
between  relations  and  we  know  what’s  going  on.  Furthermore,  in  DFQL  we  can  easily 
fellow  how  the  data  flows  from  one  part  to  the  other  part  It  is  understandable. 
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2.  FlexiblUty 

The  flexibility  w'hich  is  offered  by  each  language,  is  considered  very  useful  in 
specifsnng  queries.  Therefore,  we  feel  free  to  choose  the  techniques  which  are  most 
comfortable  and  confident  in  order  to  specify  the  correct  query.  However,  by  having 
numerous  ways  of  specifying  the  single  query,  it  may  introduce  confusion  about  which 
technique  to  use  to  specify  particular  types  of  queries  [Elma89]. 

a.  SQL 

SQL  supports  join  conditions  that  can  be  used  to  specify  many  queries  or  use 
nested  queries  with  or  without  the  /N  operator  in  it  See  Query  9.  Instead  of  using  the 
CONTAINS  operator  we  can  use  NOT  EXISTS  and  the  IN  operator  with  a  nested  query. 
Also  Query  1 1  that  uses  IN  and  OR  operatexa  can  be  specified  using  the  UNION  operate. 
Sometimes,  queries  in  which  are  involved  NOT  EXISTS  may  be  specified  using  the  IN 
t^rator  widi  nested  quay  or  vice  versa.  Query  8  is  an  examine.  It  can  be  specified  without 
the  IN  operatex’.  Generally  speaking,  there  are  numerous  ways  to  specify  the  same  query  in 
SQL  [Elina89].  However,  in  some  cases  we  have  no  confidence  that  our  query  writing  is 
well  specified  or  ccxiect 

h.  QBE 

QBE  provides  less  syntax  than  SQL  and  DFQL,  therefore  it  does  not  have  the 
flexibility  like  SQL  does.  However,  the  tuples  result  that  are  existed  in  several  relations  can 
be  fexmed  in  one  result  relation.  This  flexibility  makes  the  query  result  more  meaningful. 
See  Queries  11  and  18. 


c.  DFQL 

DF^L  provides  primitive  operators  as  described  in  Chapter  II  and  also  we 
have  been  demonstrated  in  Section  “A”  of  this  chapter.  DFQL  in  this  case,  offers  the 
flexibility  to  the  user  to  use  the  combination  or  stand  alone  of  the  primitive  operators  with 
respect  to  the  query  concern.  In  queries  which  involved  universal  quantifier,  like  Query  4, 
instead  of  using  the  groupAllSatisfy  operator  we  can  apply  the  select  and  groupCnt 
opeiatcxs.  In  Query  5,  instead  of  using  the  groupNoneSatisfy  (^)erator  we  can  also  aj^y  the 
operator  in  the  main  part  of  the  query.  In  addition,  DFQL  allows  the  user  to  define  their 
own  user-defined  operator  such  as  the  selproj  operator  of  Queries  9,  10,  22,  and  25. 
Furthermore,  the  output  of  one  query  can  be  used  as  an  input  or  as  a  part  of  another  new 
query.  In  fact,  once  we  know  the  concept  of  each  operator,  we  can  use  it  in  query 
construction  easily.  In  DFQL,  we  feel  more  confident  that  our  query  is  correct,  since  we 
can  trace  or  check  the  flow  to  the  result  part  by  part 

3.  Consistency 

As  described  before,  our  investigatirai  here  is  focused  on  the  structure  of  queries 
specified  in  each  language.  If  a  mental  model  that  we  have  for  one  sample  query  can  be 
built  or  continued  to  another  new  query,  where  the  new  query  keeps  the  same  mental  model 
of  structure  with  the  prior  query,  we  can  say  that  the  langtiage  is  consistent  in  structure. 
Consider  the  queries  in  the  single*value,  set-value,  statistical-result,  and  set-count  value 
calegtxies: 

•  Qu«y  6  is  extended  ot  combined  from  Query  4  and  5.  All  of  these  queries  involve 
universal  quantification. 

•  Query  7  and  8  involve  explicit  set 

•  Queries  12, 13, 14, 15  relate  to  A  VG  function. 

•  Queries  16, 17.  and  18  relate  to  MAX  function. 
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•  Queiy  19  is  extended  to  Query  21. 

•  Query  22  is  modified  to  Query  23,  then  Query  23  is  extended  to  Query  24.  Finally 
Query  24  is  extended  to  Query  25. 

By  using  the  various  query  examples  above,  we  can  examine  the  structure  of 
SQL,  QBE,  and  DFQL.  detail,  see  and  ctmipare  the  structure  of  each  query.  Consider 
the  following  brief  explanation: 

A  SQL 

SQL  is  not  consistent  in  structure.  If  we  attempt  to  extend  the  queries 
(complexity  increases)  as  the  queries  above,  so  far  we  caimot  apply  our  mental  model  of 
one  construct  of  query  structure  to  the  next  new  query.  In  fact,  we  have  to  rewrite  a  new 
query  frcun  the  begiiming,  which  will  often  be  very  different  in  structure  (inco.  distent)  with 
the  prior  queries.  Therefore,  inconsistency  in  specifying  queries  in  SQL,  exists  and  is 
confusing  to  the  user. 

b.  QPE 

QBE  is  very  intuitive.  In  specifying  the  queries  which  are  presented  above 
QBE  is  very  consistent  in  structure.  The  mental  models  that  ate  formed  in  one  query  can  be 
continued  to  other  new  queries  easily,  except  for  queries  that  involve  universal 
quandflcatioa.  Since  QBE  lacks  existential  and  universal  quantification  expressions,  this 
kind  of  query  caimot  be  expressed. 

e.  DFQL 

DFQL  exhibits  ccmsistency  in  structure.  If  the  queries  are  extended,  we  can 
use  the  output  of  a  query  result,  whether  a  portion  or  the  whole  of  a  previous  query,  to  be 
a  part  of  other  new  queries.  This  flexibility  is  not  exhibited  in  SQL,  nor  in  QBE  Even 
though  the  queries  are  extended  (complex'  ty  increases),  DFQL  remains  consistent  in  its 
structure  quay. 
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4.  Relative  Strengths  and  Weaknesses 


In  this  section  we  present  the  relative  strengths  and  weakness  of  these  three 
languages.  The  following  result  is  presented  by  referring  to  our  previous  discussion  plus 
s<nne  general  descriptions  of  each  language.  The  relative  strengths  and  weaknesses  d*  SQL, 
QBE,  and  DFQL  are  summarized  in  Table  3.1. 
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TABLE  3.1:  RELATIVE  STRENGTHS  AND  WEAKNESSES  OF  SQL,  QBE,  AND  DFQL. 
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TABLE  3.1:  (Conliiiiied). 
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IV.  HUMAN  FACTORS  EXPERIMENT 


A.  HUMAN  FACTORS  ANALYSIS  OF  QUERY  LANGUAGES 

There  are  several  query  languages  commercially  available,  and  there  is  a  need  to 
examine  a  variety  of  different  query  languages  in  order  to  measure  the  notion  of  “ease-of- 
use”  of  query  languages.  The  most  common  approach  in  capturing  what  is  the  query 
writing,  in  which  subjects  are  given  questions  in  English  and  asked  to  write  the 
correspoiiding  query  language  statement  [Rds81]. 

B.  EXPERIMENTAL  COMPARISON  OF  SQL,  QBE,  AND  DFQL 

In  this  section,  we  review  a  very  sinq>le  human  factors  expnimcnt  for  comparing 
SQL,  QBE,  and  DFQL.  A  general  assessment  of  the  experiment  is  provided.  Since  we 
know  that  QBE  cannot  express  universal  quantification  (see  Chapter  n.  C  1.  c),  the  tasks 
are  divided  into  two  parts: 

•  Hrst  part  consists  of  five  queries  which  can  be  specified  in  SQL  and  DFQL.  In  diis 
group  universal  quantification  is  lequixed. 

•  Second  part  consists  three  queries  which  can  be  specified  by  all  three  languages 
SQL,QB£,  and  DFQL.  Universal  quantification  is  not  included. 

This  experiment  is  not  intended  to  be  a  rigorous  comparison  of  SQL,  QBE,  and  DFQL. 

1.  Aaseasment  of  the  Experiment 

In  this  experiment  15  subjects  were  given  five  tasks  of  query  in  English  on  the 
relational  database  schema  of  Ai^)endix  A.  The  subjects  coded  or  q)ecified  each  of  the 
query  task.  Three  query  tasks  were  applied  to  all  three  quay  languages,  and  two  query  tasks 
just  applied  to  SQL  and  DFQL.  Each  response  was  then  graded  as  either  correct  or 
incorrect. 
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a.  Sublets 


The  experiment  was  conducted  on  15  students  enrolled  in  “Advance 
Database”  and  ‘^Database  Seminar”  courses  at  the  Naval  Postgraduate  School  (NFS)  in 
Monterey,  California.  The  students  at  NPS  are  primarily  U.S.  military  officers;  foreign 
military  officers  and  Department  of  Defense  civilian  employees  are  also  represented.  The 
composition  of  die  studmt  are  recorded  based  on  their  academic  backgrounds,  which  are 
broken  down  based  on  their  bachelor  degree  which  is  classified  as  “technical”  or  “non¬ 
technical”.  In  addition,  subjects  are  also  characterized  by  their  programming  experience. 
For  analysis  purposes,  subjects  widi  programming  eiqierience  more  than  1  year  are 
classified  as  "experienced”. 

b.  Teaching  MeAod 

All  the  subjects  have  already  taken  the  introductory  database  system  course 
for  one  quarter,  so  all  of  them  have  a  tackground  in  relational  algebra,  relational  calculus, 
SQL  and  QBE.  A  30  minute  presentation  of  DFQL  concept  was  given  at  the  beginning  of 
die  experiment  A  handout  describing  the  DFQL  operators  was  given  to  die  subjects. 

e.  Te^  Queries 

The  five  test  queries  were  based  on  the  relationai  database  schema  in 
Appoidix  A.  Hiey  ate: 

•  Query  Ql:  ‘list  die  name  and  location  of  die  projects  whose  member  (at  least  one) 
earns  mtne  dum  $40,000.”  The  first  query  (Ql)  involved  only  selection,  projection, 
and  joining  to  achieve  die  conect  answer. 

•  (juery  Q2:  each  project  list  the  number  of  employees  working  on  that  project” 

The  second  query  requited  groiqnng  and  counting.  Here  the  comprehension  is 
somewhat  more  complex  dian  Ql. 

•  (^uery  Q3:  ‘Retrieve  the  total  numbra  of  employees  who  worked  more  than  or  equal 
to  20  hours  in  each  project  with  mote  than  two  enqiloyees  woridng.”  The  third  query, 
in  addition  to  grouping  and  counting  operations,  also  required  special  condition  that 
needed  another  gtoiqiing  and  counting;  in  SQL,  it  is  specified  by  HAVlNG-clause. 


•  Query  Q4:  “Retrieve  the  name  of  each  en^loyee  who  works  on  all  projects  that  arc 
located  in  Houston.”  The  fourdi  query  required  the  DIVISION  opoation  of  relational 
algebra,  in  SQL  it  could  be  specified  weAer  using  (CONTAINS  conq)arison  or  NOT 
EXITS  operators.  In  DFQL,  it  can  be  specified  using  groupCoraain  operator. 
However,  since  QBE  lacks  universal  quantifier,  this  type  of  query  can  not  be 
expressed. 

•  The  question  Q5:  “List  the  first  name  and  last  name  of  all  employees  who  have  only 
female  dqiendents.”  The  fifth  query  required  the  use  of  the  universal  quantifier  and 
was  subjectively  viewed  more  difiicult  dian  the  first  three  queries,  but  almost  the  same 
widi  query  Q4.  Here,  SQL  qrplied  NOT  EXISTS  operator  in  the  WHERE-clause,  and 
in  DFQL  specified  by  the  grot^AllSatisfy  operator.  Similar  to  the  fourth  query,  it 
cannot  be  expressed  by  QBE. 

By  providing  five  queries  which  were  of  increasing  complexity,  it  was 
intended  to  see  if  DFQL  perform  better  than  SQL  and  QBE  in  more  difficult  queries. 
Subjects  were  given  one  week  to  complete  the  experiment 

d.  Evaluation  Metiufd 

The  tests  were  collected  and  hand-graded  by  die  researcher.  The  criterion 
evaluated  by  dus  aqperiment  was  graded  as  either  correct  or  incorrect  queries.  Correct 
included  te^Kmses  dial  were  either  completely  correct  or  contained  a  vninot  language  or 
minor  operand  error.  Ihe  following  taxmiomy  of  minar  language  error  aiul  minor  operand 
error  were  givoi  by  Wel^  and  Stenqile  [WdtSl].  A  minor  language  error  is  a  basically 
correct  solution  with  a  small  error  that  would  be  found  by  a  reasonably  good  translator.  A 
minor  operand  error  is  a  solution  widi  a  minor  error  in  its  data  specificatioit  such  as  a 
misspelled  column  name.  However,  a  tran^sidon  of  column  names  (or  sittqile  use  of  the 
wnmg  colurim  name)  was  classified  as  an  incmrect  answer  because  there  is  no  way  for  the 
grader,  or  cotrqniter  to  determine  the  subject’s  intent 
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2.  Experiment  Results 

ia  this  section  we  present  a  general  discussion  of  the  results  derived  from  the  data 
taken.  The  primary  measurements  of  dus  experiment  wexe  made  based  on  the  entire  sanqrle 
population.  The  primary  metric  used  was  the  number  of  questions  answered  correctly.  This 
was  calculated  for  each  individual  question  and  also  for  each  language  as  a  whole,  the  result 
are  surraiuorized  in  Table  4.1.  In  addition  we  also  provided  the  results  based  on  subject 
backgrounds  (technical/non-techrucal  and  programming  experience).  However,  since  the 
percentage  differences  between  SQL,  QBE,  and  DFQL  for  all  queries  woe  nearly  similar 
and  the  number  of  subjects  in  individual  classification  was  small  (due  to  small  overall 
population  size),  the  detailed  statistical  arutiysis  was  performed  only  on  the  total  sample, 
see  Table  4.2  and  Table  4.3. 

from  Table  4.1.,  for  the  easiest  query  (Ql),  subjects  wrote  a  greater  percentage  of 
conea  answers  in  SQL  tiian  in  QBE  (7%)  or  in  DFQL  (20%).  But,  in  Q2  there  was  a 
difference  of  53%  for  ccnect  answer  in  DFQL  compared  to  SQL  and  40%  compared  to 
QBE.  In  Q3,  there  was  only  7%  more  correct  answers  in  DFQL  compared  to  SQL  and  0% 

conyared  to  QBE.  For  Q4  the  difference  was  7%  between  DFQL  and  SQL.  In  Q5tiiere  was 

a  difference  of  33%  for  cortect  answere  in  of  DFQL  compared  to  SQL.  In  tiie  above 
analysis,  we  always  stfotract  die  SQL  and  QBE  percentages  of  correct  answers  from  DFQL; 
a  difference  of  20%  means  that  DFQL  produced  20%  more  correct  answers  than  SQL  or 
QBE. 

Table  4.2.  snmmaiizes  die  percentage  of  conect  queries  for  SQL,  QBE,  and 
DFQL  for  Q 1 ,  (}2,  and  <23  broken  down  by  technicalMon-technical  as  well  as  experienced/ 
ntm-et^erienced.  We  see  diat  the  subjects  with  a  non-technical  background  got  a  slightly 
greater  percmtage  of  queries  conect  in  all  three  languages  than  those  with  a  technical 
background.  The  difference  was  3%  more  correct  for  SQL,  2%  for  QBE,  and  9%  for  DFQL. 


In  classification  by  experience,  there  was  no  difference  in  percoitage  of  queries  correct  for 
SQL,  while  the  less  eiqwrienced  subjects  got  8%  more  correct  for  QBE  queries,  and  the 
nxne  experienced  got  3%  mote  correct  for  DFQL. 

Table  4.3.  summarizes  the  percentage  of  correct  queries  for  SQL  and  DFQL  for 
Q1  through  QS  broken  down  by  technicalMon-technical  as  well  as  experienced/hon- 
experienced  We  see  that  the  non-technical  got  a  slighfly  higher  percoitage  correct  for  both 
(3%  for  SQL  and  1%  for  DFQL).  The  experienced  subjects  got  7%  more  correa  than  die 
less  experienced  for  SQL  and  8%  more  correct  for  DFQL. 


TABLE  4.1:  EXPERIMENT  RESULT 


Task 

%  frf Correct 

SQL 

QBE 

DFQL 

Q1 

87 

80 

67 

02 

40 

53 

93 

03 

6 

13 

13 

04 

33 

Nbt^  COmpaable 

40 

05 

0 

NotComparaUe 

33 

OyemUtrftiie 
first^  paitwtaidi 
onutains 

Q1  UntNigh  Q5. 

33 

49 

SO 

OyeraDofClie 
second^  part 
whidi 
contains 
Ql,Q2,andQ3. 

44 

49 

58 

1.  Not  Companble,  since  QBE  lacks  of  univenal  quantifier. 

2.  OvenU  first  pan  is  calculated  for  all  the  doee  languages 
SQL.QBE«dlXQL. 

3.  Omall  second  pan  is  cataabued  just  for  SQL  aid  OTQL 


US 
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TABLE  4.2:  PERCENT  CORRECT  OF  SUBJECT  CLASSmCATION  FOR 

QLQ2,ANDQ3 


Subject 

OassHicatioii 

Number 
of  Subjects 

%  Of  Correct 

SQL 

QBE 

DFQL 

Technical 

7  ^ 

43'  "" 

48 

53 

Non-Technical 

8 

46 

SO 

62 

Experience  >  1  Yr. 

12 

44 

4n 

59 

Experience  ^  1  Yr. 

3 

44 

55 

56 

Total  Sanqile 

15 

44 

49 

58 

TABLE  4 J:  PERCENT  CORRECT  OF  SUBJECT  CLASSmCATION  FOR 

Q1  THROUGH  Q5 


Subject 

Qaasification 

Nundim’ 

Subjects 

%OfaMTect 

SQL 

DFQL 

Technical 

7 

31 

51 

Ncm^Teclmical 

8 

34 

52 

Expaience>  1  Yi. 

12 

32 

45 

Experience  1  Yl 

3 

39 

53 

Total  San^le 

15 

33 

50 
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3.  Eiperimait  Conduaioiis 

Generally  qwaldng,  since  this  human  factors  experiment  was  conducted  on  only 
15  subjects,  the  result  is  not  a  rigorous  statistical  comparison  of  SQL,  QBE,  and  DFQL. 
However,  we  stUl  can  make  the  following  observadons: 

a.  Qu0ry(Ql) 

SQL  is  better  than  QBE  and  DFQL  for  a  simple  query  which  involves  only 
selection,  projection,  and  joining,  Aatis  aqueiy  in  the  ring/e-vo/ue  category.  Once  the  user 
learns  and  knows  the  concq>t  of  this  type  of  query,  it  is  easy  for  the  user  to  build  anotha 
query  in  a  singie-value  category  as  long  as  the  query  requires  only  project,  select,  and  join 
tolerations.  See  a  representative  query  (Query  3)  in  Chapter  IIL  A.I.C.,  which  requites  a 
sinoile  sekcticm  and  projection  without  a  need  of  nesting.  As  long  as  nesting  is  not 
lequiied,  SQL  seems  to  provide  a  suiqile  and  logical  query  construct 

b,  Quttj((l2) 

DFQL  is  better  dian  SQL  and  QBE  for  queries  requiring  groiqring  and 
counting  operations.  This  kind  of  query  conqioses  statistical  result.  In  DFQL,  the  idea  of 
groioring  and  counting  is  easy  to  understand  since  it  requires  just  one  operator  (groupCnt). 
See  Query  14  as  one  similar  to  (22.  Li  SQL,  some  of  die  subjects  misunderstood  how  the 
CX)UNTt9erator  winks,  and  they  specified  GROUP  BY  followed  by  an  attribute  name  but 
did  not  specified  dus  attiibote  in  the  SELECT-clanse.  In  QBE,  some  of  the  subjects  mixed- 
up  the  CNT  and  CNT.  ALL  operattns. 

e.  Query  (Q3) 

hi  dus  query  all  dnee  languages  had  an  {pproximately  equal  percentage  of 
conea  answers.  (2oery  (Q3)  requires  groiqring,  counting  functions  and  qiecial  condition. 
In  S<^  the  qpedal  condition  is  known  as  HAVING  COUNT  (*),  and  in  QBE  it  is  normally 


117 


specified  using  condition  box.  In  DFQL,  it  is  fonnulaiBd  by  using  groupCnt  followed  by 
select  operators.  A  representative  of  this  kind  of  query  is  illustrated  by  Quay  21  which  is 
composed  in  set-count  value.  Chapter  QL  A.  4.  b.  Since  Q3  increases  in  complexity 
compared  to  Q2,  logically  Q3  is  more  difficult  If  subjects  did  not  have  a  good 
understanding  of  the  concept  of  this  type  of  query,  normally  they  come  up  with  incorrect 
query.  For  instance  in  SQL,  diis  query  requires  nesting,  with  GROUP  BY  and  HAVING 
COUNT  (*)  opesasors  in  the  nested  part  and  another  GROUP  BY  is  needed  for  the  whole 
query.  Therefore,  we  can  say  this  type  of  query  was  more  difficult  to  fcnmulate  in  SQL 
cofi^ared  to  QBE  and  DFQL. 

Query  (Q4) 

Query  (Q4)  exhibited  no  significant  difference  in  percentage  of  correct 
answers  between  SQL  and  DFQL.  This  type  of  query  requires  the  DIVISION  operation  of 
rdatitmal  algebra,  udtidi  is  similar  to  Query  9  {set-value  category,  sec  Chapter  HLA.  2.  d.). 
For  SQL,  this  query  is  easy  if  the  subject  understands  the  relational  division  and  the  SQL 
inylementatkm  siqipaits  die  CONTAINS  opcaiism.  fii  cases  vdxexc  die  CONTAINS 
operation  is  not  available,  it  would  be  much  more  difficult  because  eidier 

•  User  has  to  translate  relatitmai  division  into  equivalent  rdational  operations,  and  then 
write  the  SQL  corresponding  to  the  translated  relational  operations,  or 

•  Uw  has  to  re-ddnk  in  SQL  using  operations  such  as  die  NOT  EXISTS  operator.  In 
dds  case,  user  has  to  change  his/her  mmtal  model  to  negative  logic  \riiile  formulating 
die  query. 

«.  Qtiery(Q5) 

Query  (QS)  involves  existential  or  universal  quantificatioiL  hi  SQL  the  NOT 
EXISTS  and  EXISTS  operators  with  two  nested  queries  ate  requiied  to  qiecify  the  query. 
This  kind  of  query  is  similar  to  Query  10  which  is  conqxised  in  set-value,  Quqiter  ID.  A. 
Z  e.  Since  the  NOT  EXISTS  is  used  die  user  most  diink  in  die  negative  logic,  viuch  is  more 
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difficult  to  forniulate  evoi  for  ttw  e]q}ehenced  users.  Not  one  of  the  subjects  foimuhued  a 
correct  answer  in  SQL  for  this  query  (Q5).  However,  in  DFQL,  universal  quantification  can 
be  formulated  just  by  using  the  groupAllSati^  operator.  Therefore,  for  queries  which 
involve  universal  quantification,  DFQL  offers  a  more  undersiandable  approach  than  SQL. 

By  examining  these  five  tasks,  for  a  simple  query  which  requires  selection 
and  projection  without  nesting,  SQL  seems  a  simple  and  logical  construct  However,  for 
queries  which  tequiie  grouping,  counting  and  universal  quantification,  DFQL  seems  better 
in  specifying  the  query  than  QBE  and  SQL. 
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V.  CONCLUSIONS 


K- 


*1 


There  are  some  known  problems  widi  a  widely  used  quoy  language  such  as  SQL  and 
QBE.  Some  of  die  proUems  are  die  lack  of  expressing  universal  quantification,  specifying 
conqilex  nested  queries,  and  flexibility  and  consistency  in  specifying  queries  with  respect 
to  data  letrievaL  To  alleviate  these  problems,  a  new  query  language  called  *‘DFQL"  was 
proposed.  We  conducted  a  comparison  of  three  languages:  SQL,  QBE,  and  DFQL. 

Nomerous  queries  were  grouped  into  four  categories:  single-value,  set-value, 
statistical  result,  and  set-count  value;  specified  in  SQL,  QBE,  and  DFQL,  and  compared  in 
each  category.  In  die  queries  conqiaiison,  queries  ranged  from  the  simple  ones  to  queries 
uduch  are  involved  existential  or  universal  quantification  and  complex  nested  queries. 
Some  of  die  queries  are  stand-alone,  vdule  smne  odiers  specified  are  logical  «ctensions  of 
one  query  to  the  next,  with  the  conqilexity  increasing  (refer  to  (^uery  1  through  25  in 
Chapter  m).  These  rquesentadve  sets  of  queries  were  chosen  in  order  to  investigate  the 
rdadve  strengths  and  weaknesses  of  eadi  language  related  to  ease-of-use  issues,  cgiedaHy 
in  expressing  nnivenal  quantificaticm,  nested  queries,  and  flexibility  and  consistency  in 
specifying  die  queries  widi  respect  to  data  retrieval  for  RDBMS ’s. 

in  dds  research,  based  on  the  above  queries  mentioned,  and  die  analysis  which  are 
summarized  in  TaUe  3.L,  we  cmctude  that  DFQL  eliminates  the  problems  which  are 
eacoantered  and  QBE  mentioned  above.  The  relative  strengdis  of  DFQL  comes 

mainly  from  its  strict  adherence  to  relational  al^bra  and  dataflow-based  visualify.  Strict 
adherence  to  relatioital  algebra  allowed  users  not  to  worry  about  excqitions  as  was  die  case 
widi  S(^  Dataflow-baaed  visuality  required  users  only  to  master  a  very  simple  and 
iitfnitiye  dataflow  paradigm  to  write  queries.  A  simple  paradigm  of  dataflow  suffices  even 
for  a  very  conqilex  query,  because  the  ctmqilexity  of  die  query  is  handled  by  high-level, 
taer-d^bied  operations,  not  by  extending  the  language  construa  as  is  the  case  widi  the 
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other  two  languages.  Although  the  number  of  subjects  in  our  experiment  is  too  small  to 
conclude  affirmatively  that  DFQL  is  better  than  the  other  two,  the  result  of  the  experiment 
showed  that  DFQL’s  ease  of  query  writing  resulted  in  a  greater  percentage  of  conect 
queries,  especially  queries  which  involved  count,  grouping  functions  and  universal 
quant^cation  (complex  qiMties),  than  in  eitl^  SQL  or  QBE. 
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